My Domain is required for this org / Lightning components require My Domain to be deployed

You spin up a scratch org for a new feature. The deploy runs cleanly. You open the Lightning page in the browser, and instead of your component, you see a banner: My Domain is required for this org. Lightning components require My Domain to be deployed. The page won't load. The component is fine. The org isn't ready.

What My Domain actually is

My Domain is a per-org subdomain on the salesforce.com platform: https://yourcompany.my.salesforce.com instead of the generic https://login.salesforce.com. Once deployed, it changes how users authenticate, how URLs are constructed, and which features are enabled.

The platform requires My Domain for a long list of features:

• Lightning components (any LWC or Aura UI surface).
• Connected Apps and OAuth flows.
• Single sign-on (SSO), SAML, and identity providers.
• Communities and Experience Cloud sites.
• Salesforce-to-Salesforce integrations.
• Many third-party integrations that rely on stable subdomain URLs.

Without My Domain, the org runs on the generic shared domain, and the platform refuses to load any feature that depends on a per-org URL. The Lightning runtime is one of the strictest enforcers; it fails fast with the message you're seeing.

Why this happens

Three common scenarios produce the error.

A new scratch org without explicit My Domain setup. Scratch orgs created from a project's project-scratch-def.json inherit feature flags and settings, but My Domain isn't always pre-deployed. The first feature that requires it surfaces the failure.

A new trial org. Trial orgs (developer edition, professional trial) ship with some defaults but not all. My Domain may need to be deployed manually.

A sandbox refresh that lost the deployment state. Sandboxes copy production data and metadata, but the My Domain deployment state is a per-org runtime property. A fresh sandbox sometimes has the setting configured but not "deployed," and the Lightning runtime treats that as not-deployed.

The fix: deploy My Domain in Setup

The official path is via the Setup UI.

1. Setup → My Domain (search "My Domain" in the quick find).
2. The page shows the current state. If not deployed, you'll see a button labeled "Register My Domain" or "Set Up My Domain."
3. Enter a subdomain prefix (e.g., acme-dev). The platform checks availability.
4. Save. The platform begins provisioning.
5. After provisioning (usually 5-15 minutes), refresh the page. A "Deploy to Users" button appears.
6. Click "Deploy to Users." This is the step that actually makes the domain active for all users.

Once deployed, the org's URL changes from the generic https://*.salesforce.com to https://acme-dev.my.salesforce.com. All users are signed out and must log in via the new URL on their next session.

The broken example

A scratch-org definition file that doesn't account for My Domain:

{
  "orgName": "MyDev",
  "edition": "Developer",
  "features": ["EnableSetPasswordInApi"],
  "settings": {
    "lightningExperienceSettings": {
      "enableS1DesktopEnabled": true
    }
  }
}

A scratch org from this definition starts with Lightning enabled but no My Domain. Any LWC deploy works (the bundle lands cleanly), but when you try to view the component in a Lightning App, the runtime throws the error.

The fixed example

Two changes: ensure the scratch-org definition includes the right My Domain handling, and the post-create automation deploys it.

{
  "orgName": "MyDev",
  "edition": "Developer",
  "features": ["EnableSetPasswordInApi"],
  "settings": {
    "lightningExperienceSettings": {
      "enableS1DesktopEnabled": true
    },
    "myDomainSettings": {
      "loginPolicy": "RequireLoginFromSalesforceOnly",
      "redirectToCustomDomain": true
    }
  }
}

And a post-create command in your scratch-org creation script:

#!/bin/bash
set -e
ORG_ALIAS="my-dev-org"

# 1. Create the scratch org.
sf org create scratch --definition-file config/project-scratch-def.json --alias "$ORG_ALIAS" --duration-days 30

# 2. Deploy source.
sf project deploy start --target-org "$ORG_ALIAS"

# 3. Open the org for manual My Domain deploy (if not auto-handled).
echo "Scratch org ready. If Lightning components don't render, deploy My Domain via Setup."
sf org open --target-org "$ORG_ALIAS" --path /lightning/setup/OrgDomain/home

For repeatable automation, the My Domain registration step itself isn't fully scriptable from the CLI. Most teams handle it manually for new scratch orgs and accept that one-time setup step.

The CLI workaround for some setups

sf org create scratch accepts a --admin-email flag that can trigger some auto-provisioning. For orgs that should have My Domain pre-deployed (most modern scratch-org templates do), the platform handles it during creation. Confirm with the org's Setup → My Domain page after creation.

If you're working with an org that doesn't have My Domain and you can't deploy it through the standard UI (rare, but possible for some legacy editions), the Domain Management node in Setup has finer-grained controls.

A common surprise: the URL changes

After deploying My Domain, every saved URL with the old generic format becomes a 302 redirect. Bookmarks, integration webhook callbacks, OAuth callback URLs, and any hardcoded URL string in code all need to be updated to the new subdomain.

The platform redirects for a grace period (configurable in Setup → My Domain → Policies), but the right move is to update integrations within the grace window. Code that hardcodes https://yourorg.salesforce.com/ should be rewritten to use URL.getOrgDomainURL() (in Apex) or LWC.getOrgDomainUrl() (in LWC) so it stays correct across renames.

Authentication implications

My Domain changes the login URL. Users who used to log in at login.salesforce.com are redirected to yourcompany.my.salesforce.com/login after deployment. SAML and SSO configurations need to be updated to use the new subdomain in the entity ID and login URL fields.

A common deployment misstep: the My Domain is provisioned but not "deployed to users." The org has the new URL configured but is still serving the old URL for live sessions. Lightning components partially work (because the My Domain exists in some platform contexts) but fail in others. Always click "Deploy to Users" after provisioning, and confirm by logging out and back in with the new URL.

Diagnosing post-deploy

After deploying My Domain, walk through this verification:

1. The login URL works. Open https://yourorg.my.salesforce.com/ in an incognito window. The login page should appear.
2. The current user's URL reflects the new domain. Look at the browser address bar after login. It should be https://yourorg.lightning.force.com/....
3. A Lightning page renders. Open any record page (e.g., an Account). The Lightning runtime should load without the "My Domain required" banner.
4. A Connected App callback works. Log out, log in via OAuth from a Connected App. The OAuth flow should redirect to the new subdomain.

If any of these fail, the deployment is incomplete. Setup → My Domain → Deploy to Users completes the chain.

When the error appears intermittently

Some users see the error while others don't. The cause is usually a cached browser session that pre-dates the My Domain deployment. The browser holds the old URL in its session cookie; the platform doesn't recognize the cookie under the new domain.

Fix: have users log out fully, clear their browser cache for salesforce.com, and log in fresh via the new URL. The intermittent error disappears once everyone's session is on the new domain.

For automated tests and integrations, regenerate any stored access tokens after the My Domain deployment. Old tokens may be valid only on the old domain.

The relationship with Enhanced Domains

Salesforce has been rolling out Enhanced Domains alongside My Domain. Enhanced Domains add a stable, predictable URL structure for content distribution and security. As of recent releases, Enhanced Domains is enabled by default for new orgs and is becoming mandatory across the platform.

The two concepts work together: My Domain gives you a per-org subdomain; Enhanced Domains standardizes the URL structure within that subdomain. If your org has My Domain but not Enhanced Domains, some features (especially newer Lightning Experience capabilities) may still report missing configuration.

To enable Enhanced Domains: Setup → My Domain → Routing and Policies → Enhanced Domains. The toggle takes effect after a deployment step similar to the original My Domain deployment.

For an org that's been around for several years, the upgrade path runs My Domain → Enhanced Domains → done. New orgs created after the Spring '23 release usually have both pre-deployed.

A deployment workflow that prevents this entirely

For teams that spin up many scratch orgs, the most reliable workflow is to bake the My Domain handling into your npm run or make scripts. A representative pattern:

1. Read the desired My Domain prefix from a config file or environment variable.
2. Run sf org create scratch with the prefix in the org alias.
3. Wait for the org to be ready.
4. Open the My Domain setup URL in a browser tab using sf org open --path /lightning/setup/OrgDomain/home.
5. Print clear instructions to the developer: "Click Register, then Deploy to Users."
6. After the developer confirms, continue with the source deploy.

The workflow trades a minute of manual interaction for predictable My Domain state on every scratch org. Teams that have scripted this fully report no recurrence of the error.

A subtle case: source deploys that depend on My Domain features

Some metadata types (Connected Apps, Communities, certain Lightning Apps) reference the My Domain URL in their configuration. Deploying these against an org without My Domain produces obscure deploy errors that don't always name My Domain as the cause.

If a source deploy fails with messages about invalid URLs or unrecognized hostnames in Connected App or Community metadata, check My Domain first. The fix is to deploy My Domain, then retry the source deploy.

Why the platform makes this a hard requirement

A historical note: in early Salesforce, all orgs shared the same login URL. Per-org subdomains were optional, used by larger customers who wanted branding or SSO. Lightning, when it launched, made stable per-org URLs central to its security model: components are sandboxed by origin, OAuth flows depend on stable callback URLs, content security policies are pinned to specific domains.

Without a unique per-org domain, none of those security properties hold. The Lightning runtime refusing to load is the platform's way of saying "I can't enforce my security model without My Domain, so I won't render at all." Forcing the requirement up front is safer than rendering with a degraded security profile and hoping nothing goes wrong.

The trade-off is the one-time setup friction every new org pays. For most teams, it's a five-minute step the first time and never an issue again.

A diagnostic shortcut

If you're not sure whether My Domain is the cause of an obscure Lightning error, run this from Anonymous Apex:

System.debug('Org Domain URL: ' + URL.getOrgDomainURL());
System.debug('Base URL: ' + URL.getSalesforceBaseUrl().toExternalForm());

If URL.getOrgDomainURL() returns null or a generic *.salesforce.com URL, My Domain isn't deployed. If it returns https://yourcompany.my.salesforce.com, you're good and the bug is elsewhere.

The diagnostic takes ten seconds. It eliminates "is this a My Domain issue?" as a question and lets you focus on the actual cause.

Further reading from Salesforce

• Salesforce Help: My Domain
• Salesforce Help: Set Up Your My Domain
• Lightning Web Components Developer Guide: Enable My Domain
• Salesforce Help: Deploy My Domain Login URL Changes
• Salesforce CLI: scratch org definition file