Is it possible to run Apex in the context of a different user?

Specifically, we are building a custom Partner Community. We want to share some information about some custom objects but we want to prohibit the users in this community to be able to use API or other APEX to access the data.

E.g. is it possible that we treat Salesforce like a database - where the user is talking to the Apex code and only that Apex code can see the fields, whereas if the user went to, say, standard record page, or made an API call, or used other Apex (not developed by us, for example), they could NOT see any data about the records. 

So ideally we would not give 'Read' access to an object to these users instead having our code only be authorised to access this data.

Kind of like in a traditional web app, where your FE authorises you to the backend but the user that accesses the DB has nothing to do with the user that accesses your Front End?

1 Answer 1


In answer to your question title, you cannot run Apex as another user directly**, but you don't need to in order to achieve your goals.

Except for anonymous apex, apex runs in system mode so can access and manage data on behalf of the user that the user cannot access otherwise (including UI and REST API etc.). If you apply sharing you can also decide whether or not this affects the queries and DML in your code base using a class declaration "with sharing" or "without sharing" (plus inherited sharing).

If you use managed code from your own managed package you can have a protected custom object. Being protected it is only visible to your managed package.

Using these points together it is possible to ensure that the custom object records can only be accessed and manipulated via your own packaged APIs and Apex.

Note that new features are coming to support user mode in apex and the declared intent from Salesforce is to eventually flip the default execution mode for Apex to be user mode rather than system mode.

You should also note that managed packages can only be put on the app exchange after passing a security review from Salesforce. To do what is listed here (explicitly ignore the user's permissions in your apex code) is something you would have to explicitly explain and list as false positive CRUD/FLS violations. Of course, you can create a managed package without listing it (and thus having it reviewed) if you are doing so just for yourself.

NB: To handle false positives, we tend to ensure that this is documented in the code itself. For example, if we do a query without permission checks we would have something like:

for (Account account : [SELECT Scope__c FROM Account // CRUD/FLS False Positive: permissions are not checked because ...
        WHERE ...]) {

It's on the end of the first line that forms a statement and simply goes as long as required. This way, when Checkmarx flags the false positive, our whole comment explaining why it is a false positive is included in the generated report.

The same applies to DMLs and the field assignments and object instantiations that precede them.

**: Platform event apex trigger based subscribers run as a different user but that isn't necessary to use here.

  • So yeah, I did vaguely know that but since I have been developing mostly Managed Package code, the OLS/FLS was drilled into me so badly that I didn't realise that in Apex you can, indeed, access things that user's profile can't access. This part is not in a managed package as otherwise I would need to provide a false positive document, even though this is actually better security than giving people access. Thanks for reminding me
    – zaitsman
    May 20, 2022 at 6:53
  • I've being doing ISV managed package development for the last 5 years and it's definitely the case you have to drill into folks to remember to apply the CRUD/FLS checks. However, we have many cases where we need "side-effect" processing, updating records and fields the user has no access to, so false positives are common for us.
    – Phil W
    May 20, 2022 at 7:08
  • I am extremely lucky in that I was spared that, we use package install user and a bunch of batchables to do all this kind of work.
    – zaitsman
    May 20, 2022 at 7:11
  • We have some schedulables that the "ghost user" sets up in the installer. However, we know we need to move away from this because it causes its own permissions issues; the "ghost user" is missing certain permissions that means some of our processing fails with newer versions of the Salesforce platform. But that's a completely different story!
    – Phil W
    May 20, 2022 at 7:17

You must log in to answer this question.

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