Given a scenario, determine the implications to record and field data access.
Salesforce provides several tools to control access to data. Access can be controlled on a profile, user, object, and record level. Whether a user has access to a certain object, field, or record, depends on the combination of all permission and sharing settings.
To control access to objects, object permissions can be defined on profiles or permission sets for each object. To control access to individual fields on objects, field permissions can be defined on profiles or permission sets for each field. Access to data can either be specified on objects or records. On objects, org-wide defaults, role hierarchy and sharing rules can be defined. On records, manual sharing, queues, and teams can be specified.
|Object Permissions||Field Permissions||Object Sharing||Record Sharing|
|Object Permissions||Field Permissions||Org-Wide Defaults||Manual Sharing|
Access to objects can be specified with object permissions on profiles or permission sets. For each object, the object permissions define the access users have to create, read, edit and delete (CRUD) records.
In addition, to create, read, edit and delete access levels, the object permissions View All and Modify All exist. Those permissions do not respect sharing settings, and users can access all records of the object, regardless of sharing settings.
Access to individual fields on objects can be specified with field permissions on profiles or permission sets. For each object, field permissions define the access users have to read and edit fields.
The Salesforce search does not respect field permissions. Users can search for values in fields for which they have no Read permission. However, if search terms match, the associated records will be returned without fields and values for which users have no Read permission.
Roll-up summary and formula fields can be made visible to users even if they reference fields for which users have no Read field permission.
The default level of access to records can be specified with org-wide defaults (OWDs) for many objects. OWDs can be defined for the standard objects Account, Contract, Asset, Contact, Activities, Campaign, Case, Lead, Opportunity, Calendar, Price Book and Order, as well as custom objects.
Following OWDs are available for the standard objects Account, Contract, Asset, Contact, Campaign, Case, Lead, Opportunity, and Order, as well as custom objects:
For the Case and Lead objects, following OWD is available in addition:
For the Campaign object, following OWD is available in addition:
For the Calendar object, following OWD are available:
For the Price Book object, following OWD are available:
For the Activity object, following OWD are available:
For the User object, following OWD are available:
For objects with OWDs other than Public Read/Write, record access can be opened up to users who are not record owners by defining a role hierarchy.
The role hierarchy grants access vertically along the company hierarchy. Each user can be assigned to one role level, and read and edit all records owned by or shared with users below in the role hierarchy.
Opening up record access through the role hierarchy can be deactivated for individual custom objects, by disabling the Grant Access Using Hierarchies option in the OWDs. This option is always selected on standard objects and is not editable.
Additionally, roles role can give users access to cases, contacts, and opportunities, regardless of who owns those records. For example, roles can be defined that users in a role can edit all opportunities associated with accounts that they own, regardless of who owns the opportunities.
For objects with OWDs other than Public Read/Write, record access can be opened up to users who are not record owners by defining sharing rules.
While the role hierarchy grants access vertically along the company hierarchy, sharing rules allow to open up access horizontally in the hierarchy. However, sharing rules cannot restrict records access beyond what is specified in the OWDs and the role hierarchy.
Sharing rules can either be based on the role of the record owner, or criteria-based on field values of records.
Manual sharing can be defined in the OWDs settings, to allow or prevent users from sharing their own records with any other users or roles across the organization.
If the manual sharing feature is globally enabled, record owners can click the Sharing button on the record detail page, and select any role, public group, or individual users to share the record with. Record owners can also specify the access level they want to share the record with (Read Only, Read/Write or Private). The Sharing button for manual sharing is currently not available in Lightning Experience without customization (Spring ‘17).
Queues allow groups of users to manage a shared workload more effectively. Queues act as record owners and can also be used to share records for supported objects. All queue members and users in a higher role hierarchy level can read and edit records owned by a queue.
Queues are available for the standard objects Case, Lead, Order, Contract, Knowledge Article, as well as custom objects. When creating a queue, the supported objects and queue members can be defined.
Teams are groups of users that work together on an account, sales opportunity, or case. They allow record owners to share access to their records. Record owners can define an individual team for each record, or specify and reuse a default team. For account teams, team members also get access to any contact, opportunity, and case record associated with an account.
Teams are available for the standard objects Account, Opportunity, and Case. When specifying a team, the record owner can define the access level to the shared record for each team member (Read Only or Read/Write). Additionally, the record owner can specify a role for each member.
Each Community user has a profile and assigned to an Account or Contact. Different tools are available to share records owned by internal Salesforce users with Community users, and records owned by Community users with internal Salesforce users.
The available sharing tools depend on the licenses assigned to the Community users. There are three types of Community Licenses: Community User, Community User Plus, and Partner Community.
|Sharing Tool||Community User||Community User Plus||Partner Community|
|External Org-Wide Defaults|
External org-wide defaults (OWDs) can be used to set different default access levels to objects for external Community users than for internal Salesforce users.
As for internal OWDs, following external OWDs are available for the standard objects Account, Contract, Asset, Contact, Case, Opportunity, Order, User, as well as custom objects:
The external OWD must always be more restrictive or equal to the internal OWD. Community users cannot be granted more access to an object than to internal Salesforce users.
Users with a Customer Community license (i.e. High-Volume Community Users) don't have Role and therefore don't get access to records based on the Role Hierarchy.
Sharing Sets can be used to share records with High-Volume Community Users, based on their Profile and the Account or Contact associated with them. Unlike Sharing Rules, only one Sharing Set per profile and object can be defined.
Because Customer Community license users (i.e. High-Volume Community Users) don't have a Role, records owned by them are also not shared with other users based on the Role Hierarchy.
Sharing Groups can be used to share records owned by High-Volume Community Users with internal Salesforce users.