function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion
Roth2842Roth2842 

Salesforce running context when using @remoteAction vs. standard method Call

I am trying to submit a custom object for approval from a remoteAction. Up to this point, we have been using a Apex pageReference controller method, which has been working as expected.

The Approval request has been built as follows:

public static string submitQuote(id quoteId){
    Approval.ProcessSubmitRequest req1 = new Approval.ProcessSubmitRequest();
    req1.setComments('Submitting for Approval');
    req1.setObjectId(q.id);
    req1.setNextApproverIds(new ID[]{UserInfo.getUserId()});
    Approval.ProcessResult pr = Approval.process(req1);
    return 'Success';
}

 



If we call the submitQuote from the standard method it works in all cases we have identified. When we call the method using the remote action AND the running user is not the Opportunity owner or the Quote creator (these are the initial submitters on the approval workflow), they get this error:

NO_APPLICABLE_PROCESS, No applicable approval process found.

 



the Opportunity owner and or quote creator can submit using the remote action with out error.

Is there a reason that the workflow wouldn't apply when called by a remoteAction but would be accepted when not? Is there anyway to get both calls to run in the same context, so they will work and not work similarly?

Best Answer chosen by Admin (Salesforce Developers) 
Roth2842Roth2842

Salesforce Documentation Using the with sharing or without sharing Keywords

Apex generally runs in system context; that is, the current user's permissions, 
field-level security, and sharing rules aren’t taken into account during code execution.

Note
The only exceptions to this rule are Apex code that is executed with the executeAnonymous call. 
executeAnonymous always executes using the full permissions of the current user. 
For more information on executeAnonymous, see Anonymous Blocks.