I have developed a Lightning Web Component in a sandbox, consisting of HTML, JS, some actions and a few Apex classes. I have tested this as sysadmin and as another non-sysadmin user. No problems.

With a change set I have uploaded this to our QA sandbox. As sysadmin everything is working OK, so all parts have arrived in the QA sandbox.

But trying to use the LWC as another user gives the error "You do not have access to the Apex class named XYZ". XYZ exists, I have verified that and as sysadmin the LWC works.

So of course I checked the security settings for the class on both sandboxes and they are identical.

I checked profile and permission sets of the user: identical.

The user can access the LWC, because the error complains of an Apex class that is called by the LWC.

The main difference is that the first sandbox is where the LWC is created. So it seems that something is missing in the change set, which is essential for non-sysadmin users.

I am sure I am missing something simple, but what is it?

  • 2
    Were profile settings included in the change set deployment?
    – David Reed
    Apr 7, 2020 at 15:02
  • Are there any fields/objects involved?
    – sfdcfox
    Apr 7, 2020 at 15:41
  • @DavidReed No, because I hadn't changed anything with respect to profiles. I have never needed to involve profile settings in change sets. But I'll look into it. Apr 8, 2020 at 6:14
  • @DavidReed I added profile settings to the change set and did a new deployment. Just as I thought, it didn't make a difference. Same error. LWC shows up for a short moment, then it calls Apex and then I get the error. Apr 8, 2020 at 6:35
  • @sfdcfox Yes, but they are always accessed via Apex. Anyway, I checked the involved fields and the field level security is what it should be. Apr 8, 2020 at 6:41

2 Answers 2


Well, I solved it and it turned out to be profile related, but the solution is mystifying to me, very unsatisfactory.

In the sandbox in which I develop, the only profile that has access to the class XYZ is sysadmin. Other users can use the Apex class, because it is not accessed directly, but via the JS code in my LWC.

But on the QA sandbox, I had to add the profiles of the non-sysadmin users to the allowed profiles of class XYZ. And then it works.

I don't understand. The sandbox in which I develop is a Developer sandbox. The QA is a Partial Copy sandbox. It almost seems like there is some global/org setting that differs between these two sandboxes and that gives non-sysadmin users access to Apex classes in the Developer sandbox.

UPDATE: my latter hunch was right, there was an org-wide setting that was different between the two sandboxes. Two critical updates had been activated in the QA sandbox, but not in the developer sandbox. These were:

  • Use with sharing for @AuraEnabled Apex Controllers with Implicit Sharing
  • Restrict Access to @AuraEnabled Apex Methods for Authenticated Users Based on User Profile

The second one turned out to be the culprit. Activating the updates in the developer sandbox produced the same results for non-admin users as I had seen in the QA sandbox.


I solved this issue from my Scheduled Daily Flow Builder applying the Critical Update that limited and generated the error.

You must log in to answer this question.

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