System mode is nothing but running apex code by ignoring user’s permissions. For example, if logged in user does not have create permission but they will able to create a record.
In system mode, Apex code has access to all objects and fields permissions, field-level security, sharing rules aren’t applied for the current user. This is to ensure that code won’t fail to run because of hidden fields or objects for a user.
In Salesforce, all apex code run in system mode. It ignores user’s permissions. Only exception is anonymous blocks like developer console and standard controllers. Even runAs() method doesn’t enforce user permissions or field-level permissions, it only enforces record sharing.
User Mode:
User mode is nothing but running apex code by respecting user’s permissions and sharing of records. For example, if logged in user does not have create permission they are not able to create a record.
In User mode, Profile level permissions, field-level security, and sharing rules are applied for the current user.
In Salesforce, only standard controllers and anonymous blocks like developer console run in user mode.
Mode of execution:
Trigger – System
Validation Rule – System
Auto Response Rule – System
Assignment Rule – System
Workflow Rule – System
Escalation Rule – System
All Types of calculation behind formula, Rollup Summary – System
Process Builder – System
Visual Workflow or flow – User
if flow is called from Process Builder – System
if flow is called from Workflow – System
if flow is called from Apex – (depends on with or without sharing of apex class)
if flow is called from Custom Button – System
if flow is embed in Visualforce – Depends on VFP context
if flow is called from REST API – System
Approval Process – System
Publisher Action – System
InvocableMethod
if this is called from flow – User
if this is called from Process Builder (does it depends on with or without sharing is specified on that Class) – System
if this is called from REST API – (depends on with or without sharing of the class)
Custom Button – System
Test method with System.runAs() – User
Test method without System.runAs() – System
Visualforce Page (StandardController) – User
Visualforce Page (StandardController with extension) – System
Visualforce Page (Custom Controller)
depends on with or without sharing of the controller
Visualforce Component – depends on Visualforce page where it is used
Macros – System
Annonymous Apex – User
Chatter in Apex – User
Email Service – User
All types of Jobs – System
Apex Webservices (SOAP API and REST API) – System (Consequently, the current user’s credentials are not used, and any user who has access to these methods can use their full power, regardless of permissions, field-level security, or sharing rules.)
If you are setting your docType="html-5.0" and having a validation error on cancel, after the immediate="true" for a command button, action function etc.
Here are two options for disable all validation for all command buttons and disable validations for specific command button.
Option 1:
If your requirement is to disable all validation for entire page, then you can add html-novalidate="novalidate" attribute to apex form. This will disable all validations for all command buttons.
Option 2:
If your requirement is to disable the validation for specific command button, then you can add immediate="true" and html-formnovalidate="formnovalidate" attribute to that command button. This will disable all validations for all command buttons.
Big Object means 100s of billions of record on AppCloud.
It is a new capability with highly scalable object to store and manage large amount of data on the Salesforce platform.
This feature helps to engage directly with customers by preserving all your historical customer event data.
Big Objects are built by Salesforce to provide consistent performance whether there is 1 million records, 100 million, or even 10 billion records.
Use Cases:
Audit and Tracking: Track and maintain a long-term view of your user’s usage of Salesforce or your customer’s usage of your products for analysis or compliance purposes.
360 view of Customers: Now data models can be extended to contain billing infos/ecommerce transactions/any other info related to customers.
Historical Data Archive: Maintain access to historical data for analysis or compliance purposes while optimizing the performance of your core CRM or Force.com applications.
Considerations:
It is provided as a pilot to selected premium customers.
The Big Objects cannot be created from the UI. We have to take help of the Metadata APIs to create one.
Big Objects don’t support triggers however they support object and field permissions.
BigObject don’t support standard UI elements (Home Pages, Detail Pages, List Views), But It can be used in Visualforce Page and Lightning components.
Data can be populated to the Big Objects via SFDC APIs/Bulk APIs/using Apex(insertImmediate() method).
The only SOQL relationship queries available are based on a lookup field from a BigObject to a standard or custom object.
Mostly Async SOQL would be used for the querying the Big Objects. Single level child-to-parent relationship queries and aggregate queries are supported.
Big Objects don’t support transactions.
We can create up to 100 Big Objects per org. The limits for BigObject fields are similar to the limits on custom objects, and depend on your org’s license type.
Big Objects don’t appear in the Setup UI until they are deployed.