Dear awesome readers,

This post was actually written many years ago but it is still relevant.
It is a must have knowledge for all Salesforce admins and devs.

Sharing rules can never be stricter than the OWD settings.

Sharing Access Diagram:

  1. Salesforce checks whether user’s profile has object level permission to access that object
  2. Salesforce checks whether user’s profile has any administrative permissions (view all data, modify all data)
  3. Salesforce checks the ownership of the record (Organization wide defaults, role-level access, any sharing rules will be checked)

Controlling a user’s access to data in several ways:

  1. To control access to applications and objects, including fields and record types within objects: Use profiles andpermission sets. (Create record types for a custom object to display different picklist values and page layouts to different users based on their profiles.)
  2. To control access to specific records: Use sharing settings and rules.

You cannot delegate administrative duties related to your organization to partner portal or Customer Portal users. However, you can delegate some portal administrative duties to portal users.



  1. Object level security: (What objects can a user see?) (It is set in user Profiles and Permission sets) to prevent user from viewing, creating, editing or deleting any instance of a particular type of object. It allows us to hide whole tabs & objects from particular users. User wouldn’t even know the object exists. (Tab settings, Standard / Custom object permissions) On the platform, we set object-level access with object permissions in user profiles and permission sets
  2. Field level security: (What fields on those objects can a user see?) (In user Profiles and permission sets) (Field level access with field permissions) a variation of object level security. User is prevented from a particular field without having to hide the whole object, such as “max salary” or “SS”. Page layouts only control the visibility of field on detail and edit pages whereas field level security controls the visibility of fields in any part of the app (related lists, list views, reports and search results)(in order to be absolutely sure that a user does not have access to a particular field) (visible/ read only boxes checked – read only | only visible box checked – editable | no box – hidden) In the platform, we control access to individual fields with field-level security. Field-level security controls whether a user can see, edit, and delete the value for a particular field on an object.
  3. Record level security: (Org. wide defaults (Which records should be hidden by default?), Role hierarchy / Sharing model / Manual sharing (What exceptions should we make?))

Organization-wide defaults allow us to specify the baseline level of access that a user has in your organization. For example, we can make it so that any user can see any record of a particular object to which their object permissions give them access, but so that they’ll need extra permissions to actually edit one.

Role hierarchies allow us to make sure that a manager will always have access to the same records as his or her subordinates.

Sharing rules allow us to make automatic exceptions to organization-wide defaults for particular groups of users.

Manual sharing allows record owners to give read and edit permissions to folks who might not have access to the record any other way.

Profiles: (compulsory when setting up the user, user must be associated with a profile)

A collection of settings (what user can see) and Permissions (what user can do)

A profile contains user permissions and access settings that control what users can do within their organization.Profiles are typically defined by a user’s job function (for example, system administrator or sales representative), but you can have profiles for anything that makes sense for your organization. A profile can be assigned to many users, but a user can be assigned to only one profile at a time, where all of the members of the group have the same folder permissions and access to the same software. Profile never override organization’s sharing model or role hierarchy.(Exp: A profile set to allow a user access to create, edit, delete leads but a user with above profile cannot edit, delete other users leads if organizations lead sharing model is read only)

Profiles control:

o   Which standard and custom apps users can view?

o   Which tabs users can view?

o   Which record types are available to users?

o   Which page layouts users see?

o   Object permissions that allow users to create, read, edit, and delete records

o   Which fields within objects users can view and edit

o   Admin Permissions that allow users to manage the system and apps within it

o   Which Apex classes and Visualforce pages users can access

o   Which desktop clients users can access

o   The hours during which and IP addresses from which users can log in (profile login hours, Profile IP addresses)

o   Which service provider’s users can access (if Salesforce is enabled as an identity provider)

You can use standard profiles, or create, edit, and delete custom profiles. For standard profiles, only certain settings can be changed. You can never edit object permissions on a standard profile. So you must first clone the standard profile to create a custom profile and then assign user and then use permission sets to grant additional permissions.

When a custom object is created, most profiles don’t give access to the object (except those with “modify all data” under Profiles| Standard Object Permissions and Custom Object Permissions)

Standard profiles (6 Types): Marketing user, Contract manager, Read only (executive team), Solution manager, Standard user, System Admin.

Permission Sets: (Administrative and General) (Standard object permissions, custom object permissions) is acollection of settings and permissions that determine what a user can do.  If the custom box is not checked it is a standard profile and we cannot edit standard profiles permission set. But we can choose which tabs should appear at top of user’s / profile’s page and also select which apps to display in Force.com. (Default on (displayed on top of user’s page), Default off (hidden from user’s page but available when all Tabs is clicked), Tab hidden (completely hidden)

Hiding a tab is not sufficient to prevent a user from accessing records of that tab

You can only assign permission sets that have the same user licenses as the user or permission sets with no associated license. You cannot change the license later. Select the type of users who will use this permission set:

Who will use this permission set? If you plan to assign this permission set to multiple users with different licenses, choose ‘–None–‘. If only users with one type of license will use this permission set, choose the same license that’s associated with them.

  1. Grant access to custom object or App:

Example: Many users in an organization are doing the same job. Assign them all one profile that grants them access to do their job and then assign permission sets to user if they are assigned to a special project. PMISFBAC board profile, PMISFBAC operations profile (DB permission set, Volunteer app review permission set, certifications app permission set) & take away when it is not needed.

  1. Temporary/long term permission set:

Example: A user goes to vacation. Create a permission set to grant access to a custom object or app to another user. After main man returns remove it.

Difference between profiles and permission sets?

o   Users can have only one profile, but they can have many permission sets

o   Therefore profiles are used to grand the minimum permissions and settings that every type of user needs. (Assigned before permission sets)

o   Then use permission sets to grant additional permissions without changing anyone’s profiles. (Also, permission sets can be temporary or long term)

Example: (Recruiting App)

Recruiter: Own profile

Hiring Manager: Permission sets

Standard Employees: Start with low profile + permission sets

Interviewers: Any employee can be an interviewer (grant and revoke access as needed) so permission set.

Although there is permission to create, read or edit on an object does not necessarily mean users will be allowed to read every object’s record because:

  1. Permissions on a record always evaluated according to a combination of object, field and record level permissions
  2. When object vs. record level permissions conflict, the most restrictive setting wins. (If a record level is more restrictive, although object level allows it, still the record level wins because it is more restrictive)
  3. Describe the features and capabilities of the sharing model

Record Access (Record level security)

Changing your sharing model deletes any manual shares your users have created.

Ownership: Record owners can view/edit, transfer, delete records. They can also view but not edit the Accounts their records are associated to.

Org wide defaults: The administrator can define the default-sharing model for your organization by setting organization-wide defaults. Organization-wide defaults specify the default level of access to records. Allow us tospecify a baseline level of access that any user has in the org. Exp: Any user can see any record of an object but they will need extra permission to edit a record/object.

  1. Private: This setting for a given object allows users to access only the data they own. No one will be able to view records owned by others.
  2. Public Read only: This setting allows users to see, but not change, records in their organization, regardless of who owns those items. Items can also be added by anyone onto related lists with this permission level. (Providing objects have a Look up relationship)
  3. Public Read/Write: This setting allows all users the ability to view and edit records owned by others. But ownership itself cannot be changed except by the owner.
  4. Public Read/Write/Transfer: This setting on an object allows all users the ability to view, edit, and even change ownership of records owned by other

You can’t change the organization-wide sharing default setting for some objects:

o   Solutions are always Public Read/Write.

o   Service contracts are always Private.

o   The ability to view or edit a document, report, or dashboard is based on a user’s access to the folder in which it’s stored.

o   Users can only view the forecasts of other users who are placed below them in the role hierarchy, unless forecast sharing is enabled. For more information, see Manually Sharing a Forecast.

o   When a custom object is on the detail side of a master-detail relationship with a standard object, its organization-wide default is set to Controlled by Parent and it is not editable.

o   You can’t change the organization-wide default settings from private to public for a custom object if Apex code uses the sharing entries associated with that object. For example, if Apex code retrieves the users and groups who have sharing access on a custom object Invoice__c (represented as Invoice__share in the code), you can’t change the object’s organization-wide sharing setting from private to public.

1) Roles Hierarchy: Open up access (vertical) Create role hierarchy to give access to the managers of the account owners (managers inherit the privileges of user below them) (Allows to make sure that a manager will always have access to the same records as his subordinates) users who need access to same records can be grouped together} Sharing rules.

Exceptions to Role Hierarchy-based Sharing

o   Users can always view and edit all data owned by or shared with users below them in the role hierarchy. Exceptions to this include:

o   An option (Grant Access Using Hierarchies) on your organization-wide default allows you to ignore the hierarchies when determining access to data. Grant using hierarchies cannot be disabled for standard objects.

o   Contacts that are not linked to an account are always private. Only the owner of the contact and administrators can view it. Contact sharing rules do not apply to private contacts.

o   Notes and attachments marked as private via the Private checkbox are accessible only to the person who attached them and administrators.

o   Events marked as private via the Private checkbox are accessible only by the event owner. Other users cannot see the event details when viewing the event owner’s calendar. However, users with the “View All Data” or “Modify All Data” permission can see private event details in reports and searches, or when viewing other users’ calendars.

o   Users above a record owner in the role hierarchy can only view or edit the record owner’s records if they have the “Read” or “Edit” object permission for the type of record

2) Sharing rules:  (based on record owner or criteria) open up access (horizontal/lateral), used by the admin it is a way to automatically grant users access to objects when OWD or Role hierarchy doesn’t allow it. (Allows making automatic exceptions to organization wide defaults for a particular group of users) (Sharing rules works best if used on a predicted group of users {Roles}. Exp: Recruiters all belong to either recruiting manager or recruiter roles, sharing rules works best but for interviewers, a new set of interviewer will be assigned for each job. Hiring manager will be using a different set of interviewees depending on the position they are hiring for. Team of interviewees is hard to predict. )(Manage Users | Public Groups){use public groups when defining a sharing rule for more than 1 person or group or role}

o   Sharing rules allow you to selectively grant data access to defined sets of users.

o   You can use sharing rules to grant wider access to data. You cannot restrict access below your organization-wide default levels.

o   Sharing rules apply to all new and existing records that meet the definition of the source data set.

o   Sharing rules apply to both active and inactive users.

o   When you change the access levels for a sharing rule, all existing records are automatically updated to reflect the new access levels.

o   When you delete a sharing rule, the sharing access created by that rule is automatically removed.

o   When you transfer records from one user to another, the sharing rules are reevaluated to add or remove access to the transferred records as necessary.

o   When you modify which users are in a group, role, or territory, the sharing rules are reevaluated to add or remove access as necessary.

o   Sharing rules automatically grant additional access to related records. For example, opportunity sharing rules give role or group members access to the account associated with the shared opportunity if they do not already have it. Likewise, contact and case sharing rules provide the role or group members with access to the associated account as well.

o   If multiple sharing rules give a user different levels of access to a record, the user gets the most permissive access level.

o   Users in the role hierarchy are automatically granted the same access that users below them in the hierarchy have from a sharing rule, provided that the object is a standard object or the Grant Access Using Hierarchies option is selected.

o   Regardless of sharing rules, users can, at a minimum, view the accounts in their territories. Also, users can be granted access to view and edit the contacts, opportunities, and cases associated with their territories’ accounts.

o   Making changes to sharing rules may require changing a large number of records at once. To process these changes efficiently, you request may be queued and you may receive an email notification when the process has completed.

o   You can create rules to share records between most types of Customer Portal users and Salesforce users. Similarly, you can create sharing rules between Customer Portal users from different accounts as long as they have the Customer Portal Manager user license. However, you can’t include high-volume portal users in sharing rules because they don’t have roles and can’t be in public groups.

o   You can easily convert sharing rules that include Roles, Internal and Portal Subordinates to include Roles and Internal Subordinates instead by using the Convert Portal User Access wizard. Furthermore, you can use this wizard to convert any publicly accessible report, dashboard, and document folders to folders that are accessible by all users except for portal users.

o   Lead sharing rules do not automatically grant access to lead information after leads are converted into account, contact, and opportunity records.

o   In a master detail object relationship, you cannot create a sharing rule for a detail object, it is inherited.

Sharing rules based on Record owner or based on Criteria:

Criteria-based sharing rules determine whom to share records with based on field values in records. For example, let’s say you use a custom object for job applications, with a custom picklist field named “Department.” You can create a criteria-based sharing rule that shares all job applications in which the Department field is set to “IT” with all IT managers in your organization.

Although criteria-based sharing rules are based on values in the records and not the record owners, a role or territory hierarchy still allows users higher in the hierarchy to access the records.

You can create criteria-based sharing rules for accounts, opportunities, cases, contacts, leads, campaigns, and custom objects. You can create up to 50 criteria-based sharing rules per object.

3) Manual sharing: open up access (flexible), for owners or users with full access to give users read/write access to another user or group who might not have access to the record any other way.

4) Implicit access (Accounts and associated child records)

5) Teams (Account, Case, and Opportunity)

In environments where the sharing model for an object has been set to Private or Public Read Only, an administrator can grant users additional access to records by setting up a role hierarchy and defining sharing rules. Role hierarchies and sharing rules can only be used to grant additional access—they cannot be used to restrict access to records beyond what was originally specified with the sharing model through organization-wide defaults.

Roles: (principal element in sharing rules, users can be grouped into roles based on their need to access data. Each role in hierarchy should represent a level of data access required by users)

Depending on your sharing settings, roles can control the level of visibility that users have into your organization’s data.  If the Grant Access Using Hierarchies option is disabled for a custom object, only the record owner and users granted access by the organization-wide defaults receive access to the object’s records. You can create up to 500 roles for your organization.

Every user must be assigned to a role, or their data will not display in opportunity reports, forecast roll-ups, and other displays based on roles. If your organization uses territory management, forecasts are based on the territory hierarchy rather than the role hierarchy.

Role Name: The unique name used by the API and managed packages. The name must begin with a letter and use only alphanumeric characters and underscores. The name cannot end with an underscore or have two consecutive underscores.

Sharing Groups: These groups are automatically created and maintained. The Role group contains all users in this role plus all users in roles above this role. The Role and Subordinates group contains all users in this role plus all users in roles above and below this role in the hierarchy. The Role and Internal Subordinates group (available if Customer Portals or partner portals are enabled for your organization) contains all users in this role plus all users in roles above and below this role, excluding Customer Portal and partner portal users.

Users that gain access to data due to their position in hierarchies do so based on a setting in your organization-wide defaults (Grant Access Using Hierarchies)

Roles control Records: Roles primarily control a user’s record level access permissions through role hierarchy and sharing rules. Roles is the easiest way to define record level access permissions.

Profiles and Permission Sets control a user’s object & field level access permissions: A user can’t be defined without being assigned to a particular profile, since the profile specifies the most basic access for users. Each role in the hierarchy should just represent a level of data access that a user or group of users needs.



  1. Given a scenario, apply the appropriate security controls
  2. Who is the most restricted user of this object?

(Standard employee)

  1. Is there ever going to be an instance of this object that this user shouldn’t be allowed to see?

(Yes – Sharing model is Private)

(No) 3. Is there ever going to be an instance of this object that this user shouldn’t be allowed to edit?

(Yes – Sharing model is Public Read Only)(No – Sharing model is Public Read/Write)

  1. Describe the various profiles controls

Standard profiles:

System Admin: Has access to all functionality that does not require an additional license. For example, administrators cannot manage campaigns unless they also have a Marketing User license.

Standard platform user: Can use custom apps and the apps from Appexchange + can use core platform functionality such as accounts, contacts, reports, dashboards, and custom tabs

Solution manager: Can review and publish solutions. Also has access to the same functionality as the Standard User

Marketing user: Can manage campaigns, import leads, create letterheads, create HTML email templates, manage public documents, and update campaign history via the import wizards. Also has access to the same functionality as the Standard User.

Partner user: Can only log in via a partner portal.

Customer portal user/manager: Can only log in via a Customer Portal. Can view and edit data they directly own or data owned by or shared with users below them in the Customer Portal role hierarchy; and they can view and edit cases where they are listed in the Contact Name field.

Contract manager: Can create, edit, activate, and approve contracts. This profile can also delete contracts as long as they are not activated. Can edit personal quota and override forecasts.

Read only: (executive team) Can view the organization’s setup, run and export reports, and view, but not edit, other records.

Chatter user/moderator: Can only log in to Chatter. Can access all standard Chatter people, profiles, groups, and files.

Site.com user: Can only log in to the Site.com app. Each Site.com Only user also needs a Site.com Publisher feature license to create and publish sites, or a Site.com Contributor feature license to edit the site’s content

  1. Given a scenario, determine the appropriate use of a custom profile

A profile is a collection of permissions and other settings associated with a user or a group of users. Your organization has a number of standard profiles already defined. If you create a custom object, the permissions to access that object (“Read,” “Create,” “Edit,” and “Delete”) are disabled for most profiles. This security setting ensures that access to custom objects and their data is only explicitly granted to users. You can change these permissions in custom profiles, but not standard profiles.

Overview of User Permissions and Access:

User permissions and access settings specify what users can do within an organization. For example, permissions determine a user’s ability to edit an object record, view the Setup menu, empty the organizational recycle bin, or reset a user’s password. Access settings determine other functions, such as access to Apex classes, app visibility, and the hours when users can log in.

Permissions and access settings are specified in user profiles and permission sets. Every user is assigned only one profile, but can also have multiple permission sets. Permission sets are the best way to apply system access to users without affecting all other users that have the same profile. (exp: permission 1 + permission 2 + permission 3 (up to 1000) grouped into a permission set to create a profile like permission without creating complete profiles.

When determining access for your users, it’s a good idea to use profiles to assign the minimum permissions and access settings for specific groups of users, then use permission sets to grant additional permissions.

Because you can assign many permission sets to users and permission sets are reusable, you can distribute access among more logical groupings of users, regardless of their primary job function. For example, you can create a permission set that gives read access to a custom object and assign it to a large group of users, and create another permission set that gives edit access to the object and assign it to only a few users. You can assign these permission sets to various types of users, regardless of their profiles.

The following table shows the types of permissions and access settings that are specified in profiles and permission sets

Delegating Data Administration: (Overriding the security and sharing configurations and who has such powers and how powers are granted) Creating a profile with “manage Users” permission is not recommended because of security risks {can expire all passwords, edit login hours, edit/delete profiles, etc.} so we use delegated administration. Limited admin privileges such as create/edit users, reset passwords, assign users to specific profiles, login as a user who granted login access)

Global Administrative permissions: “View all data”, “Modify all data” (including mass transfer / update records and Undelete what others delete) “Customize Application”—Customize just about anything in Salesforce, from page layouts to the data model

“Manage Users”—Add and remove users, reset passwords, grant permissions, and more

(Global permissions apply to records of every object in organization permissions, if global is too permissive then use object permissions) there are two ways to delegate restricted data administrative access (overriding sharing)

  1. Object level permissions: (View all, modify all) Object permissions apply to records of a specific object. Or create a permission set with “modify all” and assign to roles.
  2. Delegated Administration groups: is a group of non-admin users with limited admin privileges. Security controls | Delegated Administration
  3. Delegated Administrators: Users
  4. User Administration (Roles): lets us kinds of users this group can manage
  5. Assignable profiles: lets us specify the profiles this group can assign to users they manage.
  6. Custom Object Administration: specify custom objects delegated admins can administer.

Profiles and permission sets – Objects and fields level access permissions

Roles – Record level access permissions through role hierarchy and sharing rules

Sharing rules and role hierarchies can never be stricter than our org-wide default settings.

A public group is a collection of individual users, other groups, individual roles, and/or roles with their subordinates that all have a function in common. Using a public group when defining a sharing rule makes the rule easier to create and, more important, easier to understand later, especially if it’s one of many sharing rules that you’re trying to maintain in a large organization. You’ll need to create a public group if you ever want to define a sharing rule that encompasses more than one or two groups or roles, or any individual.

Profile controls access to objects and records using roles

One Account can have many Opportunities, many opportunities can belong to one account.

Advertisements