Generally available as of the Winter ’22 release, restriction rules can be used to control the records a specific user group is allowed to see. As per the documentation for creating a restriction rule (https://
help.salesforce.com/s/articleView?id=sf.security_restriction_rule_ create.htm&type=5), When a restriction rule is applied to a user, the data that the user has access to via org-wide defaults, sharing rules, and other sharing mechanisms is filtered by the record criteria that you specify.
At the time of writing, restriction rules are available for the following objects:
Up to two restriction rules can be created per supported object in the Enterprise and Developer editions, and up to five restriction rules per supported object in the Performance and Unlimited editions.
Now that we have an understanding of sharing and security on the Salesforce platform and how it affects data access, we can now look at each Salesforce object type.
Salesforce objects can broadly fit into one of four types. While you will no doubt have worked with the standard and custom object functionality available on the platform, it is necessary to understand how they work at a lower level to truly understand what it means to issue SOQL queries against those object types and how it affects performance. Secondly, you may not have worked with external objects and big objects before. These are different when it comes to data storage and access (external object data isn’t stored on the platform and is accessed on -demand through an external data source. Big object data ensures consistent performance but data lives in a separate location to standard/custom objects within the Salesforce platform).
sObjects
An sObject is the generic form of any Salesforce Object. The standard Salesforce objects and the custom objects you create are concrete types of sObjects (they all inherit common properties and behavior). Another way to think of an sObject is that it abstracts the actual representation of any Salesforce object, much like objects in the Java programming language all inherit from the Object base class.
Depending on your license type, Salesforce provides access to many standard objects that are designed to fulfill many business use cases with minimal customization.
These objects and their fields, in an out-of-the- box state, will all be held in the standard objects/ standard fields underlying database table. From an object access perspective, additional Salesforce licenses such as Service Cloud will essentially grant access to the underlying Service Cloud standard objects such as milestone and entitlement and their out-of-the-box fields.
Standard objects and standard fields don’t have a special suffix and therefore are represented as Account (in the example of a standard object name) and Name (in the example of a standard field name) when issuing SOQL queries. Here’s an example:
SELECT Name FROM Account
Without any customization, querying for standard object data is very fast. This is because there is only one database table being queried for. As soon as a single custom field is added to a standard object, that field is created in the Custom Objects/Custom Fields table, and therefore any queries for that field will essentially cause a JOIN query issued to the underlying Salesforce database, as we now require results from both tables.
Acedexam Training Policies
Learning resources
Other resources
Our Training Providers
