The following table lists the types of execution contexts that Apex code can be run from and considerations with respect to security and state management. While a description of how to implement each of these is outside the scope of this book, some aspects, such as Batch Apex, are discussed in more detail in a later chapter when considering data volumes:
|
Execution context |
User |
Security |
State management |
|
Anonymous Apex |
Current user |
Sharing is enforced by default, unless disabled by applying the without sharing keyword to the enclosing class. CRUD and FLS are enforced by default, but only against the code entered directly into the Execute Anonymous window. The code will fail to compile if the user does not have access to the objects or fields referenced. Note that checking is only performed by the platform at compilation time; if the code calls a pre-existing Apex class, there is no enforcement within that class and any other class it calls.
|
See Note 2. |
|
Apex Controller Action Method Note: Used only by Visualforce pages |
Current user |
Sharing is not enforced by default; the developer needs to apply the with sharing keyword to the enclosing class. CRUD and FLS are not enforced by default; the developer needs to enforce this in code. |
Any member variable declared on the Apex Controller that is not static or marked with the transient keyword will be included in View State. Visualforce automatically maintains this between interactions on the page. Use it carefully, as large View State sizes can cause performance degradation for the page. Developer Console has an excellent View State browser tool. |
|
Apex Controller Remote and Aura Actions Note: Remote Action methods are used by Visualforce and Aura Action methods are used by Lightning Components |
Current user |
Sharing is not enforced by default; the developer needs to apply the with sharing keyword to the enclosing class. It is required for Salesforce security review. CRUD and FLS are not enforced by default; the developer needs to check this in code. |
Remote Action and Aura Action Apex methods are already static, as stated previously; any static data is not retained in Apex. Thus, there is no state retained between remote action calls made by the client JavaScript. Typically, in these cases, the state of the task the user is performing is maintained on the page itself via the client-side state. As a result of not having to manage the state for the developer, these types of methods are much faster than the action methods described in the preceding section. |
|
Apex Trigger and Apex Async Trigger |
Current user
|
Sharing is not enforced by default; the developer needs to apply the with sharing keyword in the outermost Apex class (if present, for example, Apex Controller). Triggers invoked through the Salesforce UIs or APIs run without sharing implicitly; if you need to apply with sharing, move your trigger code into an Apex class and call that from the trigger code. CRUD and FLS are not enforced by default; the developer needs to enforce this in the code. |
Static variables are shared between Apex Trigger invocations within an execution context. This allows some caching of commonly used information and/or recursive trigger protection to be implemented if needed. |
|
Batch Apex |
User who submitted the job. |
Sharing is not enforced by default; the developer needs to apply the with sharing keyword to the enclosing class. CRUD and FLS are not enforced by default; the developer needs to enforce this in the code. |
Batch Apex splits work into distinct execution contexts, driven by splitting up the data into scopes (typically, 200). If the Database.Stateful interface is implemented,the class member variable values of the implementing Apex class are retained between each invocation. The transient keyword also applies here. The final keyword can be used to retain the initial member variable values throughout the job's execution. |
|
Platform event subscription |
System user (See Note 3) |
See Note 1. |
See Note 2. |
|
Package post install script |
System user (See Note 3) |
See Note 1. |
See Note 2. |
|
Queueable |
User who submitted the work |
See Note 1. |
See Note 2. |
|
Apex scheduler |
User who scheduled the job |
See Note 1. |
See Note 2. |
|
Inbound messaging |
Based on inbound message configuration |
See Note 1. |
See Note 2. |
|
Invocable method |
Current user |
See Note 1. |
See Note 2. |
|
Apex REST API |
Current user |
See Note 1. |
See Note 2. |
|
Apex Web Service |
Current user |
See Note 1. |
See Note 2. |
The following notes apply to the rows in the preceding table:
- Note 1: Unless otherwise stated in the preceding table, the default position is as follows regarding security:
- Sharing is not enforced by default; the developer needs to apply the with sharing keyword to the enclosing class.
- CRUD and FLS are not enforced by default; the developer needs to check this in the code.
- Note 2: For state management, unless stated otherwise in the previous table, the default position is as follows:
- No static or member variable values are retained between invocations of the Apex class methods between execution contexts.
- Note 3: The system user is not a physical user in the system. Be sure you understand this implication when performing database operations in this context, for example when updating and inserting records. In the case of platform event subscriptions (discussed in a later chapter), the UserId field contains the ID of the user who generated the event.