Cannot find component: c:myComponent

A user opens an Account record. The Lightning Page renders most of the layout, but one panel shows the orange triangle and the message Cannot find component: c:accountHealthSummary. The component renders fine in the developer's sandbox. It's listed in the deploy manifest. The deploy report shows green. And yet the runtime can't find it.

How the platform resolves a component reference

Every Lightning component (Aura or LWC) is uniquely identified by its namespace and its name. The platform stores each component's bundle definition keyed on those two pieces. When markup references <c:accountHealthSummary> (Aura) or <c-account-health-summary> (LWC), the runtime parses the namespace prefix (c: or c-) and the component name, then asks the bundle store for a match.

If no bundle has that exact namespace and name combination, the runtime can't instantiate the component. The user-facing message is generic. The console (in Aura's case) or the network response (in LWC's case) usually carries more detail, but the user sees only the orange triangle.

The namespace c is the default for components in your org without a managed-package prefix. Components from a managed package live in that package's namespace (acme or myPkg, for example), and references to them use <acme:doStuff> or <acme-do-stuff>.

Check 1: is the bundle in the org at all?

The fastest diagnostic is to query the Tooling API. Open the Developer Console and run:

SELECT Id, MasterLabel, NamespacePrefix
FROM LightningComponentBundle
WHERE DeveloperName = 'accountHealthSummary'

For Aura bundles:

SELECT Id, MasterLabel, NamespacePrefix
FROM AuraDefinitionBundle
WHERE DeveloperName = 'accountHealthSummary'

Run with Use Tooling API checked. If the query returns zero rows, the component isn't in the org. The deploy didn't actually include it, or it was deployed and then removed. Re-deploy from your source control branch.

From the CLI:

sf data query \
  --query "SELECT Id, MasterLabel, NamespacePrefix FROM LightningComponentBundle WHERE DeveloperName = 'accountHealthSummary'" \
  --target-org production \
  --use-tooling-api

A common pattern: a developer renames a bundle locally (accountSummary/ becomes accountHealthSummary/), deploys the new bundle, and forgets to delete the old one. The org has both. Markup references continue to work for the old name; the new name shows up in pages but the runtime resolves to whatever bundle the page configuration points at. If the page references the wrong one, you get Cannot find component.

Check 2: is the namespace right?

A reference like c:accountHealthSummary resolves to a bundle in the c namespace. Two common ways the namespace can be wrong:

The component is in a managed package. If the bundle's NamespacePrefix is acme, the correct reference is acme:accountHealthSummary (Aura) or acme-account-health-summary (LWC). Updating the reference to include the prefix usually fixes the resolution.

The org has no namespace assigned but the component was deployed assuming one. Some deployment tools strip namespace prefixes during the deploy. The bundle lands in the c namespace in production even though it carried acme in source. References that still use acme: then fail. Check the bundle's NamespacePrefix in the production org and update the references to match.

For LWC, the kebab-case reference (<c-account-health-summary>) is automatically derived from the bundle's camelCase name (accountHealthSummary). The platform handles the case conversion, but the rule is one-to-one: a bundle named myAccountSummary resolves to <c-my-account-summary>, not <c-myAccount-summary> or any other variant.

Check 3: is the component visible to this surface?

A component's .js-meta.xml file (LWC) or .cmp-meta.xml file (Aura) declares the surfaces where it can render: app pages, record pages, home pages, communities, Flow screens, and more. If the component is technically deployed but its metadata doesn't include the surface you're rendering on, the platform refuses to instantiate it from that surface and you get Cannot find component.

Sample LWC metadata that allows the component on a record page:

<?xml version="1.0" encoding="UTF-8"?>
<LightningComponentBundle xmlns="http://soap.sforce.com/2006/04/metadata">
    <apiVersion>59.0</apiVersion>
    <isExposed>true</isExposed>
    <targets>
        <target>lightning__RecordPage</target>
        <target>lightning__AppPage</target>
    </targets>
</LightningComponentBundle>

If isExposed is false, the component is private and can't be added to any user-facing surface from the Lightning App Builder. If the surface you want isn't listed in <targets>, the Lightning Page builder won't show the component in its palette, and pages that already reference it will fail at render time.

The fix is to add the missing target to the metadata and redeploy. Bumping apiVersion to a value supported by the surface is sometimes necessary as well.

The broken example

A developer adds a new LWC and references it from an existing Aura wrapper without paying attention to namespace:

<!-- Aura wrapper referencing an LWC -->
<aura:component implements="flexipage:availableForRecordHome">
    <c:accountHealthSummary recordId="{!v.recordId}"/>
</aura:component>

The LWC source folder is force-app/main/default/lwc/accountHealthSummary/. The bundle deploys to the acme namespace in production because the org has a managed-package namespace assigned. The Aura reference still uses c:, which resolves to the unmanaged c namespace. The Lightning runtime can't find a bundle named accountHealthSummary in the c namespace and shows the orange triangle.

The fixed example

Make the reference namespace-aware. The cleanest fix is to use the bundle's actual namespace in both source and references:

<!-- Aura wrapper referencing the namespace-correct LWC -->
<aura:component implements="flexipage:availableForRecordHome">
    <acme:accountHealthSummary recordId="{!v.recordId}"/>
</aura:component>

And the LWC metadata file confirms the targets the component supports:

<?xml version="1.0" encoding="UTF-8"?>
<LightningComponentBundle xmlns="http://soap.sforce.com/2006/04/metadata">
    <apiVersion>59.0</apiVersion>
    <isExposed>true</isExposed>
    <targets>
        <target>lightning__RecordPage</target>
    </targets>
    <targetConfigs>
        <targetConfig targets="lightning__RecordPage">
            <objects>
                <object>Account</object>
            </objects>
        </targetConfig>
    </targetConfigs>
</LightningComponentBundle>

The targetConfig restricts the component to Account record pages, which produces a cleaner experience in the App Builder (the component appears in the palette only when editing an Account record page).

Special cases

Built-in components like lightning:datatable failing: usually an API version mismatch. The component you're consuming lightning:datatable from has an older API version than the version that introduced datatable. Bump your component's apiVersion to 41.0 or higher.

Dynamic instantiation in Aura: $A.createComponent requires the parent to declare a <aura:dependency> for the dynamic component. Without the declaration, the platform doesn't know to load the dynamic component's definition and the call fails with Cannot find component.

LWC lwc:component dynamic rendering: similar to Aura's dynamic instantiation. The dynamic-component pattern is newer in LWC and requires explicit import of the component class.

Rename, refactor, and the version drift problem

The deepest source of Cannot find component errors in long-lived orgs is naming drift over time. A bundle named oldName gets renamed to newName in source control. The deploy creates the new bundle but doesn't delete the old one. Pages, Aura wrappers, and Flow screens still reference oldName. Half the references work, half don't, and the org slowly accumulates a graveyard of obsolete bundles whose names appear in metadata even though their bundle definitions are gone.

The fix is two parts:

• Use destructiveChanges.xml in your deploy to explicitly delete the old bundle in the same deploy that introduces the new one.
• After the deploy, search the org's metadata for references to the old name and clean them up. The Workbench tool or a metadata export script makes this manageable.

A regular "namespace and bundle audit" once a quarter catches drift before it produces user-visible errors.

When the error shows up only for some users

Cannot find component for one user but not others is almost always a permissions issue. Three sub-cases:

Profile-based component access. A component's parent Lightning App restricts which profiles see it. Users in profiles outside the allowed list see the missing-component error. Check the Lightning App's User Profiles list in Setup → App Manager.

Permission set required for the underlying object. A component that displays Account.Industry requires the user to have at least Read on Account.Industry. Users without the field permission see various flavors of error, sometimes including Cannot find component when the field-level access cascades into a Lightning Data Service load failure. Audit field-level security on the relevant objects.

License-gated features. Components that depend on a paid feature (e.g., Service Cloud Voice, Einstein Discovery) fail to render for users without the licensed seat. The component is technically deployed; the user's license bundle doesn't include the runtime support.

For each case, the fix is on the permissions side, not the component side. Don't change the component to work around the missing access; grant the access (or accept that this user's experience differs by design).

A practical checklist for the first time you see this error

When the error lands in a bug report, work through this short list before assuming the bundle is missing:

1. Open the page in the App Builder. Does the component appear in the page's component list?
2. Open the bundle in Setup → Lightning Components (LWC) or Setup → Lightning Components (Aura). Does the bundle exist? What's its namespace?
3. Compare the reference's namespace to the bundle's namespace.
4. Check the bundle's .js-meta.xml or .cmp-meta.xml: does the target list include the surface the page renders on?
5. Try the page as a System Administrator. Does the error persist? If not, it's a permissions issue.
6. Tail the browser console while reloading the page. The Aura framework often logs more detail than the user-facing message.

The list runs in increasing order of effort. Most appearances of the error resolve on step 1 or 2 (the bundle wasn't deployed, or the namespace is wrong). Steps 3 through 6 catch the trickier cases.

A small but useful diagnostic helper

Build a one-liner Apex method that lists all bundles by namespace and name. Stash it in a utility class so anyone on the team can run it from Anonymous Apex during a triage:

public class ComponentInventory {
    public static void list() {
        for (LightningComponentBundle b : [
            SELECT MasterLabel, DeveloperName, NamespacePrefix, ApiVersion
            FROM LightningComponentBundle
            ORDER BY NamespacePrefix, DeveloperName
        ]) {
            System.debug(
                String.valueOf(b.NamespacePrefix ?? 'c')
                + ':' + b.DeveloperName
                + ' (API ' + b.ApiVersion + ', label "' + b.MasterLabel + '")'
            );
        }
    }
}

Run with ComponentInventory.list(); in the Developer Console's Anonymous Apex window. The debug log shows the full inventory, which is faster than running multiple SOQL queries by hand when you're chasing a missing component.

Further reading from Salesforce

• Lightning Web Components Developer Guide: Component Bundles
• Aura Components Developer Guide: Defining a Component
• Salesforce Help: Configure a Lightning Web Component for Lightning App Builder
• Salesforce CLI Reference: project deploy commands
• Trailhead: Lightning Web Components Specialist Superbadge