Choose a company-owned subdomain for a long-running employee store when your IT team can own the address and coordinate changes with the provider. Choose a provider-hosted address when a limited campaign or pilot benefits more from a simpler setup. A third option—a company-owned landing page that links to the provider—can preserve a familiar starting point without moving the storefront itself.
The decision is not simply whether the URL looks branded. It determines who can change the destination, what employees will see during sign-in and checkout, and which links you can preserve when the program moves. Separate ownership of the address from ownership of the store, accounts and order records.
Publisher perspective: Brand Sauce publishes this company-store infrastructure guide. The decision framework is our editorial recommendation. Shopify documentation illustrates specific platform behavior; it does not establish Brand Sauce capabilities or your provider's configuration. Sources checked October 10, 2026. Custom-domain support, setup and migration services are quote-needed. The hero is conceptual AI-generated editorial art.
Compare three address models, not two logos
For illustration, imagine that your company controls example.com. A store at merch.example.com uses a company-controlled subdomain. A store under the provider's domain uses an address the provider controls. A page on your existing company site can also explain the program and send employees to that provider-hosted store.
| Model | Useful fit | Main responsibility or limitation |
|---|---|---|
| Company-owned store subdomain | An ongoing program with a durable employee-facing address | IT and the store provider must coordinate DNS, domain configuration and secure connections |
| Provider-hosted store address | A pilot, short campaign or program without available domain administration | Confirm whether the provider will preserve or redirect the address after a move |
| Company-owned entry page linking to the provider | A familiar starting point while the actual shop stays elsewhere | The browser changes domains; the entry page does not make every downstream link portable |
A provider-hosted address is not inherently a poor experience. It can be completely appropriate when employees receive a clear introduction and the program has a dependable support route. Conversely, an attractive custom address is not a substitute for working checkout, accurate allowances or a delivery plan.
Write down what the company actually controls
Ask whose organization controls the parent domain, who administers its DNS settings, and who can authorize a change. Keep the business owner and technical owner distinct. HR may approve the purpose and campaign name; IT may approve the hostname and make the routing change; the provider may configure the storefront to accept traffic for that hostname.
A vendor can manage the shopping application while the company controls its address. Those are compatible arrangements. Equally, putting your logo on a provider's page does not transfer control of the provider's domain to you. Record both facts in the service brief instead of calling the entire arrangement simply “white label.”
Shopify's official third-party subdomain instructions demonstrate the separation: a business can keep its root domain serving another website while connecting a subdomain to its store. The documented process includes changes at the domain provider and connection verification inside Shopify. Other platforms may have different requirements; obtain the instructions for the exact service you are buying.
Use an organizationally managed account and named internal responsibility for domain administration. Do not make a departing campaign coordinator the only person who knows how to request a change. The operating record needs an owner and escalation route, not a copy of anyone's password.
Distinguish routing, redirects and the displayed address
“We can point your URL at the store” is incomplete. Does the company address remain in the browser, or does the browser move to a provider address? Does it work for the homepage only, or for product pages and account journeys too? Ask the provider to demonstrate the result.
Cloudflare's CNAME explanation describes a DNS alias pointing to another hostname. It also explains that the web server still handles the requested hostname. The practical implication is that adding a DNS record alone does not establish every part of a functioning custom-domain storefront; the destination service must be configured for it.
Application-level behavior is a separate question. Shopify, for example, distinguishes primary, alias and redirect domains: a redirect sends the visitor to the primary domain, while an alias keeps its own name in the browser. See its domain-type documentation. Do not assume another provider uses those labels in the same way.
Request a short URL map covering the invitation destination, catalog, product page, sign-in, checkout and order-history page. A custom storefront domain may coexist with different account or payment destinations. Approve the actual journey rather than promising employees that they will never leave the company domain.
Choose according to program lifetime and ownership capacity
Favor a company-owned subdomain when the address becomes part of employee infrastructure. It may appear in onboarding instructions, an intranet menu and recurring recognition communications. A stable starting address is valuable when the store is expected to outlast a campaign or provider contract. Budget for ongoing ownership, not just the initial configuration.
Favor the provider address when speed and limited scope dominate. A small pilot can test product selection and fulfillment without also becoming a domain project. Keep its link in an editable internal page, and avoid printing that temporary address on materials intended to last for years. Decide what happens if the pilot becomes permanent.
Favor the entry-page model when IT cannot support a custom storefront yet. The existing company page can explain eligibility, link to the current shop and identify support. That makes the starting point maintainable, but employees who bookmark a provider product page will still bypass it. Describe this as a practical compromise, not complete portability.
Address choice is independent of merchandise production. An on-demand program, a bulk-order window and a hybrid store can each use any supported address model. Bulk can suit a fixed event quantity; on-demand can suit recurring individual orders; hybrid can combine stocked essentials with optional items. Domain branding should not decide your inventory commitments.
Make the address part of launch acceptance
Set the technical go-live before the employee announcement. Do not treat a saved DNS change as proof that the store is ready. Shopify's TLS guidance says certificate issuance can take up to 48 hours after connecting a third-party domain. That is a platform-specific planning allowance, not a universal store-launch promise.
Agree on the following acceptance checks with the people responsible for the program. These are proposed checks, not results from a Brand Sauce deployment.
- Address check: Open the exact employee-facing link on desktop and mobile. Confirm the destination, spelling and displayed hostname against the approved URL map.
- Connection check: Confirm that the intended HTTPS address loads without a certificate warning. Do not instruct employees to bypass warnings to reach their gift.
- Journey check: Complete a permitted test from the entry page through sign-in, selection and checkout. Record any domain changes so support knows which are expected.
- Deep-link check: Open a product or collection link directly, not just from the homepage. Check links in the actual invitation and approved reminder template.
- Permission check: Verify the intended browsing and ordering restrictions separately. A branded address is not a rule about who may spend company funds.
- Recovery check: Identify who handles an unavailable store, how employees find help, and who may authorize routing changes or a temporary announcement.
The company-store launch checklist covers the wider program. Treat domain acceptance as one part of that release, not as a reason to skip product, budget or fulfillment checks. A completed technical setup does not prove that the employee offer is ready.
Plan the provider exit before printing the address
A company-controlled hostname gives you a point you can reconfigure, but it does not automatically migrate the store. The new provider must support the intended domain. Product paths may change. Existing account links, gift links and order-history links may depend on the old application. Inventory, balances and open orders require their own handoff.
Create a small link register: link location, current destination, responsible owner and replacement plan. Start with the intranet, onboarding documents, QR codes on durable materials and recurring message templates. Mark links you can edit separately from links already distributed. This is more useful than assuming that keeping the hostname preserves every URL beneath it.
In the exit agreement, ask who will retain access to old order information, whether any old addresses can redirect, how long transition support lasts, and what must happen before the previous service closes. Apply the broader swag-provider migration checklist to orders, artwork and balances. Moving the front door is only one workstream.
Illustrative scenario: A company has one intranet link, four onboarding documents and three printed QR-code designs. Changing the intranet destination fixes one controlled entry point, not all eight assets. If the QR codes point to a company-controlled entry page, their destination can be updated there. If they point directly to old provider pages, the team needs provider cooperation or replacement materials. This is an example of link ownership, not a measured customer outcome.
A copyable domain brief for your provider
- Preferred model: company subdomain, provider address, or company entry page.
- Internal owners: program approver, domain administrator and backup contact.
- Supported scope: storefront, accounts, checkout and order-history destinations, with any exceptions.
- Setup: required records, verification process, certificate responsibility and change window.
- Acceptance: named tester, approved URL map and evidence of the complete recipient journey.
- Ongoing service: monitoring, incident escalation, renewal responsibilities and change authorization.
- Exit: domain release steps, old-link handling, transition duration and quoted charges.
Request separate pricing for custom-domain setup, continuing support and migration work when those are not included. Do not infer that the shortest URL is the cheapest option. If comparing a managed company-store proposal, ask the team to walk through this brief using your own proposed address before committing to the launch date.
Frequently asked questions
Does a company-domain store mean the company hosts it?
No. The company can control the address while a provider operates the application. Confirm responsibility for both layers and keep a documented path for changes.
Does a familiar domain replace invitation verification?
No. Explain the approved program through an established internal channel, including expected destinations and support. The gift-invitation verification guide covers that communication. Address branding and recipient verification solve different problems.
Can we launch on the provider's address and change later?
Potentially, if the platform supports the new domain and the transition is planned. Ask what happens to old links, existing sessions and account journeys. Avoid promising a seamless switch before the provider demonstrates the required behavior.
Is a separate domain necessary for each campaign?
Not necessarily. A stable store or entry page may route employees to the appropriate campaign within the supported application. Choose separate addresses only when the audience, ownership or experience genuinely requires them; otherwise each new address adds another item to maintain and retire.
