The release notes for the critical update Enable Dependency Access Checks In Lightning Components state that access checks will be done on all components when the update is activated. Previously, access checks would only apply to the top level component.

When the critical update is activated, the framework checks the access allowed for the top-level component and each component dependency, including any permissions needed to access each component. When the critical update isn't activated, the framework checks access for the top-level component only.

Step five of the activation steps state to upgrade any managed packages that contain lightning components. This implies that the update applies to managed packages.

  1. If you have installed any packages that contain a Lightning component, upgrade to the latest version.

I have a managed package that contains lightning components. One component 'GlobalParent' has an access level of 'global'. 'GlobalParent' contains/depends on a non-global component 'PrivateChild'. I'd assume that when I drag 'GlobalParent' onto my community that 'PrivateChild' would fail the access check and I would see an error. I do not see an error.

If you're thinking that maybe the update isn't active then I'm with you! I have another question here about that. I was pointed to this issue which indicates the update is active in my org.

What does this update actually do?

3 Answers 3


If the profile do not have access to the apex class then the server call will fail and you will get the component error pop up. if you handled error properly in the JS file then you get the handled error message.

  • I understand the permissions. The trouble I'm having is with this portion of the release notes: "The access system attribute indicates whether the resource can be used outside of its own namespace... the framework checks the access allowed for the top- level component and each component dependency" -- this seems to imply that the framework will check each component dependency to be global.
    – bafuda
    Jul 6, 2020 at 19:35

I suspect, without any evidence, that Salesforce are probably referring to explicit dependencies denoted via an aura:dependency tag for dynamically created components, rather than implicit dependencies defined via markup.

I wonder if you find a component in your managed package that makes use of the explicit dependency syntax, and see if it fails when the dependency is not accessible to the user.


Answer from Salesforce support:

Till now:

We checked the top-level component access. If the user had access to the top level component, we use to assume that all child components are allowed (irrespective of namespaces).


As per the latest update (CRUC), it would check for each level of component access for access. If the namespace changes, the access check is re-evaluated. So, now, we block access to that component which does not match the parent component namespace and is not global.

The top-level component needs to be global if accessed outside the org. Access check will be performed if the namespace is changed.

Here is an example

top level component (ns: c)
L1 component (ns: x) -- check performed
L2 component (ns :x)
L2 component (ns : x)
L2 component (ns : y) -- check performed
L1 component (ns: y) --check performed
L1 component (ns: c)

This is just like apex methods. If a method is not global, it can not be used (only in scenarios where namespace changes).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .