Describe the 4 Levels of Access Controls Provided by the Salesforce Platform
- Org Level Access (SFDC access)
- Profile Level Access (Object CRUD & Gross Data Visibility Controls)
- Record Level Access (Row level/Sharing Visibilty)
- Field Level Access (FLS)
How a User is Allowed to Access Salesforce?
All questions must result in YES to be approved:
- Is the Username & Password correct?
- Does the user fit into valid IP range and/or Valid Login Hours?
- Has the user been authenticated in a second factor?
- Token based, email based, etc…
Login Approved
How is a request by a user to view record of a certain object handled at the Profile Level?
Any Question that results in Yes allows object level access, no’s keep going down the line:
- Does the User have View All Data/Modify All Data Profile Permission?
- Does the User have View All/Modify All at Object level?
- Does the User have R/U (read/update) at Object level on profile?
- Does the User have R/U on a Permission Set assigned to them?
If no all the way, no access to record.
The “View All” and “Modify All” object permissions give users access to all of an object’s records, regardless of record-level access settings.
What are the decision steps required to grant access to a record of a certain object?
Any answer of Yes to the following questions results in allowing record access.
- is the record owner = running user?
- is the OWD on the object = Public (R/O or R/W)
- Role Hierarchy & Sharing (which ever is least permissive)
- Is there a record in the Direct Sharing Table granting access (R or U)
- Is there a record in the Group Membership Table granting Access (R or U)
No to both 3-1 and 3-2 results in insufficient access. if one is R and the other is U, R will win. (least permissive)
Types of Record Level ‘Access’
Record level access is defined as either record Reading (R in CRUD) or record Editing (U in CRUD)
ie when a public read/only record is shared, the actual grant changes from read to update.
How is a users request (page layout load) to view or edit a certain field handled?
yes to either question here results in granted FLS access, which is then checked against Page layout presence.
- Is FLS for field R/U on Profile?
- Is FLS for field R/U on Permission Set?
Finally is Field present on Page Layout?
What is the definition OWDs and how are they used?
Org Wide Defaults
Definition: Default Sharing patterns and levels, set in the Sharing Settings section of setup. They define the MOST RESTRICTIVE that record level access can be to users who DO NOT OWN the record. Owners have full CRUD (usually)
I.E. If an object is set to Public Read/Only it is impossible to restrict Read Access to a certain record if that user has Read access on the object itself.
Values:
- Public Read/Write: everyone can see and edit all records (CRUD level settings still rule over object, P R/W on account but you can restrict C or U on all account records)
- Public Read/Only: Base sharing grants read access on all records not owned by the user.
- Private: user can only see records she is a direct owner of (or has another sharing mechanism to see)
What considerations are there for allowing an object’s record sharing access to be controlled by a parent object?
Specific to only the following objects:
- Order
- Contact
- Asset
- Activities
Default access carries through to the default of the parent object (i.e. order controlled by oppty, contact controlled by account, etc.)
What does OWDs control about record access via Role hierarchies?
For Standard Objects, record access is granted through role hierarchies (this cannot be disabled). (i.e. I can see all the Accounts that my direct reports own, when OWD is private or pub R/O)
For Custom Objects: Grant access using hierarchies is selectable.
In order to simplify sharing, Salesforce provides an easy way to share records with managers. To use this sharing rule, an admin must first add the user to a role and grant access.
Role hierarchies only share records UP the hierarchy.
What are the mechanisms via which record sharing access is controlled in Salesforce?
- OWDs
- Role Hierarchy
- Territory Hierarchy
- Sharing Rules
- Teams
- Manual Sharing
- Programmatic Sharing
What are the Details of How Salesforce Platform Manages Record Access Grants?
SFDC uses explicit access grants, maintained in a table for each object with CustomObject_sharing or StdObjectShare naming conventions.
- if OWD is Public R/W, no sharing Table is maintained for that object as all records are fully accessible by all users
- to maintain the 300ms page render target, sharing grants are calculated when configuration or data changes cause changes to the grants.
- grant tables have access level allowed, record id of share subject, user or group id of who to share to, and sharing reason attributes (rowCause)
- Grant Types:
- Group Membership - User joins group, queue, role, territory
- Inherited Grants -gain through group, queue, role, territory hierarchy
- Implicit Grants - non-configurable grant (termed built-in sharing, For example, with this default logic, users can view a parent account record if they have access to its child opportunity, case, or contact record.)
if the level of sharing requested during the transaction does not explicitly exist then the access is denied.
Salesforce uses explicit grants when records are shared directly to users or groups. Specifically, Salesforce uses explicit grants when:
- A user or a queue becomes the owner of a record.
- A sharing rule shares the record to a personal or public group, a queue, a role, or a territory. (Except with Enterprise Territory Mgmt no territory sharing groups)
- An assignment rule shares the record to a user or a queue.
- A territory assignment rule shares the record to a territory.
- A user manually shares the record to a user, a personal or public group, a queue, a role, or a territory. (Except with Enterprise Territory Mgmt no territory share)
- A user becomes part of a team for an account, opportunity, or case.
- A programmatic customization shares the record to a user, a personal or public group, a queue, a role, or a territory. (Except with Enterprise Territory Mgmt no territory shares programmatically)
Describe Declarative Sharing Rules and Their Types
Role Hierarchies only share records vertically and up the hierarchy, for lateral sharing, we must rely other mechanisms. Two of which are set declaratively:
- Ownership-based Sharing Rules
- Ownership-based sharing rules let admins share records based on role, role-and-subordinate, and public group ownership.
For example, we can share all the records owned by anyone in a sales executive role with everyone in a service executive role. Similarly, we can share all the records owned by the sales executives, and their subordinates, with others as well.
- Criteria-based Sharing Rules
- Criteria-based sharing rules let users access records based on the value of a field in a record, irrespective of who owns the record. For example, if someone wants to meet with all accounts in San Francisco, she might set a criteria-based sharing rule on all accounts whose billing city is San Francisco.
Every Object gets a set of sharing rules (unless they are controlled by parent)
Manual Sharing
Warning, Currently in Classic only!
Record-level-security provides a mechanism to share individual records with others. This permission is accessed through the Sharing button on the record details page, and lets end-users share individual record with others.
Note: This is only available if the OWD is private or public read-only because otherwise (say public read/write), you wouldn’t need it and there is no sharing table.
Sharing Reason (rowCause) = Manual
Apex Managed Sharing
Apex managed sharing provides developers with the ability to support an application’s particular sharing requirements programmatically through Apex or the SOAP API. This type of sharing is similar to Force.com managed sharing. Only users with “Modify All Data” permission can add or change Apex managed sharing on a record. Apex managed sharing is maintained across record owner changes.
Considerations:
Apex Triggers and User Record Sharing
If a trigger changes the owner of a record, the running user must have read access to the new owner’s user record if the trigger is started through the following:
- API
- Standard user interface
- Standard Visualforce controller
- Class defined with the with sharing keyword
If a trigger is started through a class that’s not defined with the with sharing keyword, the trigger runs in system mode. In this case, the trigger doesn’t require the running user to have specific access.
Share all the ways implicit sharing grants record access.
- ownership on case gives account share
- Controlled by parent
- activities
- orders
- contracts
*
