In each Salesforce organization, the administrator is the key holder: they are the guardian of the company's data and thus their main concern is protecting this valuable asset. The right object permissions shape data according to the kind of user who accesses it, while planning the right sharing strategy enables users to see only the subset of records they are authorized to read and/or write, thus delivering coherent and safe business processes.
In this chapter, we will learn about the following topics:
- How data security is handled within the Salesforce platform
- The difference between profiles and permission sets to define what users can do
- Setting up record-level security to restrict/allow access to data depending on the user's shape
- The Salesforce sharing model (from organization-wide default sharing to manual sharing), which determines which objects can be accessed by whom
- Setting up Enterprise Territory Management for a territory-based record-sharing model
- Handling sharing in Salesforce communities to give external users access to data
With tens (or even thousands) of users in your Salesforce organization, choosing the right way to make data visible is an administrator priority: you have to control who sees what and you need to be aware of all the options your Salesforce customer relationship management (CRM) provides.
It's not a coincidence that secure data access is the first subject we are going to study in this book.
In my 10 years' experience, being able to master data access management has always been the key to better data organization, better platform performances, better CRM usability, and of course better customer satisfaction.
Data is your number one CRM resource, so use it carefully and with be conscious of it. Let the Salesforce platform take care of it and gently bring your sharing model to life.
Like in most applications, every data story begins with a user: they authenticate against the application, they are recognized by their credentials and profile (we're not talking about Salesforce profiles but the generic set of powers a specific kind of user has), and then they are allowed to access the application's features and a subset of the data.
A Salesforce user is identified by their license. The User License field is one of the mandatory fields of the Salesforce user object:
The available licenses can be found in Setup | Company Settings | Company Information, in the User Licenses section:
The number and type of available licenses you have depends on what your company or your customer has agreed to with Salesforce.
We can reasonably divide licenses into three groups regarding data sharing:
- Full sharing model usage users/licenses: Users within this category have full access to the Salesforce sharing system. Some objects may not be accessible (for example, the free edition cannot access base CRM objects), but the engine is still there and configurable. This class of users is usually referred to as internal users.
- High volume customer portal licenses: Users within this category do not have access to the sharing model. Instead, sharing is enabled by matching user fields with other object's relations (for example, the contact lookup on the user is used to provide access to cases with the same contact value). This class of users is generally used in Salesforce communities.
- Chatter-free license: This category doesn't have access to the sharing model or any CRM object (standard or custom) and it features collaboration-only access (chatter, groups, and people, to name a few).
In a few words, the license constrains the kind of powers a user has, which is then delivered with profiles and permission sets. We'll take a look at these in the upcoming sections.
One of the first steps when designing a new Salesforce CRM implementation is to set up data access using the sharing model engine. This specifies who can see what!
To understand how this works, have a look at the following diagram:
Profiles determine Object-Level Security (OLS) and Field-Level Security (FLS). They control which objects a user is allowed to access (right or write capabilities) and which fields are visible and editable. You can create a fine-grained view of what's available for a specific object type.
Permission Sets contains mostly the same attributes as profiles but they are usually added to specific users to provide additional permissions that their sole profile does not grant (it's like giving more powers to selected users). This allows them to create a small set of profiles (that applies to most users, thus reducing the amount of time needed for profile maintenance) and apply permission exceptions to given users without the need to create a brand new dedicated profile.
Supposing you already know what page layouts are, while page layouts define which fields a user can see or write to in that specific view of the record, FLS is org-wide, which means that if a profile cannot access a specific field even though a layout is set to display it, it will never be accessed by that profile.
That's why layouts are used to organize data rather than limit its access (for example, a sales user should read the contact fields on a given case with the Contact Request record type, even if he is not interested in reading those fields on the Payment Confirmation record type, but at the profile level the FLS on those fields are not changed).
After profile configuration, record-level access configuration comes next:
- The Organization-Wide Defaults (OWD) define how users have access to each other's records: when you want to protect an object, you set up the most restrictive access type (for example, Private) and then use the other available tools to give wider access to specific subsets of users. Let's say a specific profile has access to read and write on the case object: if OWD is set to Public Read Only, a user can read all the cases but won't be able to update them unless they are the owner of the record or are allowed to due to the other sharing features.
- Role hierarchy represents a hierarchic view of the company's employee structure (such as an organization chart). This level of sharing defines how records are shared across the hierarchy (for example, sales managers can see all the records that are owned by their sales representatives).
- Sharing rules are exception rules that can give wider access to records or a group of users who shouldn't actually see those records because of OWD and Role Hierarchy configurations.
- Sharing sets/groups are used to share records with Salesforce community users.
- Users can be given the power to share records they own with other users who don't have access to them otherwise. This is called manual/Apex sharing, and although it's not an automated configuration, it gives your users the needed flexibility to work with their team members.
- Use team sharing to grant access to specific records (for opportunity, account, and case objects only): the record's owner (or users who are higher in the role hierarchy or administrators) can create a team granting read-only or read/write access to their team users to access the record. You can only have one team per object.
- Territory hierarchies is a feature that's specific for accounts, opportunities, and their child records (records that have a master-child relation with them). You can provide access to records based on specific one-dimensional division (for example, business units, zip code, and country) using territory sharing rules, which are recalculated every time the record changes its territory-linked fields.
- Apex sharing is the most powerful and granular feature that can give your sharing needs the right way to control record access if the previous features are not enough or don't apply to your sharing model. Developers can create algorithms to programmatically share objects with whichever users/groups they need to.
One final kind of sharing is implicit sharing, which is related to specifically standard objects and is a native feature that cannot be switched off. Parent implicit sharing means that if a user has access to opportunities, cases, or contacts, they also have access to the parent account. Child implicit sharing is the opposite; it gives users access to child objects (contacts, opportunities, and cases) to the owner of a given account: the administrator can set up read, write, or no access for child sharing in the role definition.
The following diagram summarizes the previous concepts:
Let's dig deeper into each way we can grant access to records.
Profiles define how users can access data and the whole Salesforce application.
Your organization comes with standard profiles that (there are exceptions for some Salesforce editions, such as contact manager, group edition, or essentials edition), you can customize a few permissions for on a standard profile or clone (creating a new custom profile) so that you have full access to its customization (for example, custom object access, field-level security access). The only thing you cannot change is the license type related to a profile.
Permission sets are similar to profiles with a simple difference: you can assign zero or more permission sets to a single user, thus providing additional capabilities that are not set up in the base profile. This increases permissions attribution granularity when creating simple profiles with few capabilities and granting users different powers as needed (sometimes, a Salesforce user can have both sales and service capabilities, but you don't want to create a profile with both permissions).
You may ask the following question:
You definitely can, but only if your users have clear permission needs and their operative role in the CRM is well defined, which is usually not the case. The business can ask for the sales representatives to be able to access and edit cases, though some service agents may be required to edit opportunities, which are a sales representative's unique permission. If you have to take into account any exceptions when setting up permissions, you would end up with tens of custom profiles, a task that can be time-consuming. Instead, you should deliver some base and exclusive profile configuration and provide a class of permissions using permission sets to specific users when needed (a user can have only one profile but can be related to multiple permission sets).
You can edit a profile with two different interfaces: the enhanced profile user interface and the original (or standard) profile interface.
To enable the Enhanced Profile User Interface, click on Setup | Users | User Management Settings and enable the Enhanced Profile User Interface flag:
This interface is a more powerful profile editing page that supports all the settings that are provided by the original interface: the main enhancement is the capability to search for settings as opposed to the original interface, where all the main options are in a single page. To switch from a master setting to a child one, you need to browse different pages.
From now on, we'll be using the original interface.
Let's briefly look at every section on the profile editor page:
- Profile Detail: This section contains the main details of the profile, including whether it is a standard profile or a custom one. This section is editable on custom profiles only.
- Console Settings: Edit layout assignment in Salesforce console apps.
- Page Layouts: This section is used to assign layouts to records (and record types if the object has at least one record type).
- Field-Level Security: For each object, this defines which fields are visible and editable.
- Custom App Settings: This decides which Salesforce applications are accessible by the user and which ones are the default ones.
- Tab Settings: Like the Custom App Settings section, we can choose which tabs are enabled or hidden.Record Type Settings: For any object that supports record types, you can allow users to use them when creating a new record, thus allowing users to have access to specific business processes.
- Administrative permissions and General User Permissions: This section contains all the administrative settings and general permissions (such as the View All Data and Modify All Data superpowers). This section can only be edited for custom profiles.
- Standard Object Permissions, Custom Object Permissions, and Platform Event Permissions: These sections define the OLS, that is, CRUD operations and the View All and Modify All superpowers, which allow the user to view and modify all the records of a given type. Platform events can only be configured with read or create access.
- Session Settings and Password Policies: These sections display profile-specific session settings (such as session duration and security level) and everything about password management that overrides the Setup | Security | Session Settings and Password Policies org-wide settings.
- Login Hours: Define when a user should be able to log in to Salesforce.
- Login IP Ranges: Defined the origin IP addresses that are considered safe to access your Salesforce organization (there's a restriction on a company's IP ranges). Within this range of IPs, users won't be asked for an activation pin (this is sent via email or SMS). You can also restrict this to org-wide login so that it's executed from within this range in Setup | Security | Session Settings.
- Enabled Apex Classes Access and Enabled Visualforce Page Access: From here, you can enable access to Apex classes (for example, enable a user to access a specific custom Apex web service) and Visualforce pages (for example, access to a specific Visualforce wizard).
- Other permissions:
- External Data Source Access: Access to external records (defined in Setup | Integrations | External Data Sources).
- Named Credential Access: Access to specific external web servers (Setup | Security | Named Credentials).
- Service Presence status: Available presence statuses (for example, live chat operator status such as Active, Away, or Offline. Go to Setup | Features Settings | Service | Omni-Channel | Presence Statuses to do this. Note that you need Omni-Channel activation).
- Custom Permissions: Allows profiles to have custom permissions that have been designed to modify a Visualforce or Lightning component's behavior on the developer side and validation rules on the administrator side (Setup | Custom Code | Custom Permissions).
- Default Community: Default Salesforce community (if any).
If you want to create a new custom profile, you only have to jump to the standard profile you want to modify (or choose another custom profile that's already set up) and click the Clone button, which brings you to the following page:
From now on, the profile will be completely customizable and will be listed as a custom profile on the profile's Setup | Users | Profiles page:
Now, let's look at how we can create permission sets.
Permission sets are, as the term suggests, a collection of permissions or settings that give users access to specific platform features/functions.
Permission sets are used to extend application feature access to users without changing their profiles.
Permission sets are not used to restrict permissions: you cannot use a permission set to revoke access to a specific object of a field if another permission set or user's profile grants this permission.
This concept is valid for whatever kind of permission that's available on the permission sets.
You can create a permission set by going to Setup | Users | Permission Sets:
If you don't fill in the License field, you won't be able to see all the possible settings. Only use no license permission sets when you want to apply them to users whose license is allowed to enable it.
The permission set editor uses the enhanced profile view:
The Session Activation Required flag is used to create permissions sets that are associated with specific kinds of sessions.
The following limitations apply for the maximum number of permission sets that can be created in a given organization:
|Personal edition||Contact manager||Group edition||Essentials edition||Professional edition||Enterprise edition||Unlimited and performance edition||Developer edition|
The first level of access type is Object-Level Security (OLS), as we saw previously on the profile edit page:
These kinds of operations are usually referred to as CRUD operations:
- Update (or Edit)
Some of them respect sharing configurations while some do not:
- Read: Users can view records of this type if the sharing settings allow them to (sharing respected).
- Create: Users can create and view records (sharing respected regarding the read operation); that is, you cannot have Create without Read enabled.
- Edit: Users can edit and read records (sharing respected); there can be no Edit without Read.
- Delete: Users can read, edit, and delete records (sharing respected); there can be no Delete without Read and Edit.
- View All: Users can see all the records of this object and thus sharing is not respected.
- Modify All: Users can read, edit, delete, transfer, and run approval on all the records of this object, thereby overriding the sharing settings.
View All and Modify All work like the View All Data and Modify All Data user permissions on profiles, but there should be a better alternative to convey better access granularity to records.
Object accessibility causes the object's tab to be visible to a given user.
The concept of Field-Level Security (FLS) is easily pictured in the FLS settings for a given profile's access to an object:
You can define Read Access and Edit Access on fields (Edit Access requires Read Access). If you remove Read Access from a given field, the user won't be able to see that field on the object layout, even if the field has been added on that layout.
The same applies to Edit Access. If the record is in edit mode but the current user doesn't have Edit Access to that field, the field won't be writable.
Required fields (marked as required or master-detail fields) will always have read and edit access, while system fields (such as Created By or Created Date) will always be read-only.
You should prefer FLS to layout-specific field configurations since it reduces the number of required layouts and makes field access coherent across profiles and record types.
If you want to see what determines field access, jump to Setup | Object Manager, look for any object, click on Fields & Relations, select any field, and click on the View Field Accessibility button to see the following display:
For every record type (if any) and profile, you will have a picture of field accessibility (Hidden, Read-Only, or Editable) on the assigned profile.
Once you have selected which objects and fields a user can have CRUD access too, you need to know how to control record-level access. We can do this using Salesforce's sharing settings.
To define the Organization-Wide Defaults sharing settings, go to Setup | Security | Sharing Settings:
A selection of standard objects and all custom objects can be set in this page.
By default, Salesforce uses role hierarchies to grant access to records to the users that belong to roles above a given user hierarchy. This means that if a user owns a record (whose object is set as Private in the OWD, so it should be only visible to its owner), using hierarchies, the manager user who is above that role can access the record as well.
If you change an object's OWD to a wider value (for example, from Private to Public Read-Only) the visibility is updated instantly: users who weren't able to access the records will immediately be allowed to do so.
If you restrict access (for example, from Public Read/Write to Private), Salesforce will start a recalculation that could take hours to complete, depending on the size of the dataset.
The OWD settings have the following values (a selection object has specific values that differ from this list):
- Controlled by Parent: If a record is a child of another kind of record (for example, a contact is parented to an account), you can give this record the same access level as its parent. If a user can edit an account, then they're allowed to edit its children contacts as well. When a custom object is a master-detail child of a standard object, the only available value is Controlled by Parent and it is not editable.
- Private: Only the record's owner and users above their role hierarchy can view, edit, and report on the record.
- Public Read Only: The record is viewable and reportable by any user, but it can only be edited by its owner and users above the owner's hierarchy.
- Public Read/Write: The record is viewable and editable by any user in your organization. Only the owner can delete or manually share the record.
- Public Read/Write/Transfer: Available only on cases and leads, the transfer operation allows a record to be transferred of ownership, but only the owner can delete or manually share it.
- Public Full Access: Available only on campaigns, this allows all users to read, edit, and delete a campaign, regardless of whether they are the owner or not.
A user object has the following two available values:
- Private: A record is accessible by the owner (that is, the same user) and by the users on the hierarchy above it.
- Public Read-Only: The record is accessible by any user in the organization.
In order to improve recalculation performance, you can enable External Organization-Wide Defaults and change the way records are shared with external users (such as customer community users).
Some types of external users are as follows:
- Authenticated website users
- Chatter external users
- Community users
- Customer portal users
- Guest users
- High-volume portal users
- Partner portal users
- Service cloud portal users
It's good practice to set the Default External Access to Private and then extend accessibility using, for example, sharing rules or sharing sets for the external users only.
External access can be set for the following objects:
- Custom objects
To enable external OWD defaults, click on the Enable External Sharing Model button on the Setup | Security | Sharing Settings page. All external default values are matched with the internal settings.
With role hierarchies, users can have access to records that are owned by or have been shared with users below their hierarchy. In a few words, the CEO (the person with the highest role) can see any record owned by any user, while the Sales Manager can see records that are owned by or have been shared with sales representatives but cannot see records owned by Service Manager users.
This applies to objects with OWD set to Private or Read Only because of the principle that sharing can grant wider access and not restricted access.
To set up roles, go to Setup | Users | Roles:
You can create up to 500 roles for your organization.
Every user should have a role, otherwise their data won't show up on displays based on their role (such as an opportunities report and forecast rollups).
System administrator users may not have the role set, but it is good practice to fill in this field, especially if these users own records. If a role is not set, it is likely that their records won't appear on reports/views.
To avoid performance issues, no user should be able to own more than 10,000 records. If this is unavoidable (for example, the user is an integration user), assign that user a higher role to avoid complex sharing calculations.
Sharing rules create exceptions for OWD settings and can grant wider access to public groups, roles, and territories.
Before we look at sharing rules in detail, let's talk about Groups.
Groups are sets of users and can contain users, other groups, and all the users in a given role or territory hierarchy (or even the users below that given role/territory, that is, the so-called subordinates).
Your organization supports public groups, which are created by administrators and can be used by any user, and personal groups, which are created by any user and only accessible to them.
Groups can be created for the following reasons:
- For default sharing with sharing rules (only public)
- To share a record with other users (both public and personal)
- To share a Salesforce CRM Content library (only public)
- To assign users to a selected action on Salesforce Knowledge (only public)
Since public groups are involved in sharing calculations to increase system performance, we need to take the following into account:
- Avoid creating groups with few users (use manual sharing instead).
- Don't adopt groups for users that need frequent move in and out.
- Don't nest groups for more than five levels deep.
- Enable Grant Access Using Hierarchies on the public group configuration, but only if that group doesn't include all internal users.
A group can contain the following:
- Public groups
- Personal groups (available only when creating personal groups)
- Roles (internal and subordinates, or internal and portal subordinates)
- Partner users
- Customer portal users
Like any other sharing method other than OWD, sharing rules cannot restrict access to records.
To create a new sharing rule, go to Setup | Security | Sharing Settings, choose an object in the Sharing Rules section, and click the New button:
There are two different kinds of sharing rules:
- Owner-based: Record identification is based on ownership; for example, you can share an owned record with a given role or group
- Criteria-based: Record identification is based on the record's fields; for example, you can share a record that has the Internal Division custom field set to Utilities.
Another thing to remember is that although criteria-based rules use record fields to calculate sharing and not its owner, role and territory hierarchy could still take place (if it's not been disabled for custom objects).
The following field types can be used for criteria calculation:
- Auto number
- Lookup relationship (for the user ID or queue ID)
- Text (case-sensitive)
- Text area (case-sensitive)
If a field type you need for the criteria is not supported, create a workflow or trigger to copy that value into a text/number field.
You can even apply filter logic to create more complex criteria.
After you have decided which type of sharing rule you want to create, select the categories of users to share with (for example, roles, territories, or groups) and the sharing access level:
- Private: This is only available for associated contacts, opportunities, and cases (for example, Account Sharing Rule).
- Read only: Reads a record.
- Read/Write: Reads and updates a record.
- Full Access: Reads, updates, deletes, transfers, and shares records (just like its owner).
Once a rule has been created, the Share with value cannot be updated.
Here is an example of an Account Sharing Rule:
It shares accounts with the Billing City of Pirri or Sestu that are in an Active state to users in the Eastern Sales Team role, giving them Read Only access to the account and the related contact, case, and opportunity objects (they are specific to the account object).
The following are some considerations about sharing rules:
- If you have multiple sharing rules for a given record, the widest rule is actually applied.
- You cannot add high-volume users to sharing rules because they don't have a role.
- Sharing rules apply to all records (new and old) and are applied to active and inactive users.
- Sharing rules are also recalculated every time a user enters/exits a role, a territory, or a group or when a user transfers the record to another user.
- Because sharing calculation can take a while, Salesforce puts in a background calculation job and notifies the user with a system email when the calculation is ready.
- Lead sharing rules don't apply to account, opportunity, and contact objects that are generated after lead conversion.
Manual sharing is the ability for a record's owner to give access to that record (and also other related records) to other users who are not necessarily included in their hierarchy. If you give another user access to an account record, that user would be able to access cases and opportunities.
To manually share a record, you must either be its owner, a user above the owner's hierarchy (if Grant Access Using Hierarchies is enabled for that object), any user with full access, or a system administrator.
The Sharing button can be displayed on a record page if its OWD is set to Private or Public Read-Only.
In the following screenshot, we can see that the account has a Public Read Only OWD:
By clicking the Add button, you can set up manual sharing for the record:
In the Search field, you can include the following information (depending on the features in your organization):
- Manager groups: All the user's managers
- Manager subordinates groups: All the user's managers and their subordinates
- Public groups: Groups defined by the administrators
- Personal groups: Groups defined by the current owner
- Users: All internal users
- Roles: All the roles in your organization
- Roles and subordinates: All the roles in your organization (not available if portals are enabled)
- Roles and internal subordinates: All the roles in your organization and all the users below that role hierarchy (no portal roles considered)
- Roles and internal and portal subordinates: Like the previous point, but with portal roles and users
- Territories: All the territories defined in your organization (if territory management is enabled)
- Territories and subordinates: All the territories with the users below the territory hierarchy
We can use the Find button to search for entities to share the record with. Once we have found them, we can move them into the Share With select list. Then, we can select the required access level (Full Access, Read/Write, or Read-Only).
Once saved, this is what you will see on the record's Sharing Detail page:
You can't share a record with another user unless they have read permission on the given object, and you can't share a record if the owner is an inactive user.
When the sharing options aren't enough, or you simply need to share a given record automatically with a user or a group without changing its ownership, you can go with Apex managed sharing.
This kind of sharing is close to manual sharing but it is best used with Apex automation or external API calls (that is, the other system's operations directly into Salesforce).
How to create Apex managed sharing rules is out of the scope of this book, and you need developers to achieve this kind of custom sharing. However, you may have to consider it when sharing policies are highly complex or the other sharing methods don't deliver the required level of sharing granularity.
You can define account, opportunity, and case teams to ease collaboration on those objects and increase access levels for specific users in the team.
The concept behind opportunity teams is the same as account teams: a group of users working together for an opportunity.
Click on Setup | Feature Settings | Sales | Opportunities | Opportunity Team Settings and flag Enable Team Selling.
Member roles have the same values of account teams (Setup | Feature Settings | Sales | Team Roles), so consider this when changing the picklist values.
You can add a default team, an account team, or add new users:
The only access level you can open to the team's members is opportunity access:
The concepts of member creation and editing are the same as for account teams.
Like account and opportunity teams, case teams are meant to enhance the service process: define people that can have access to the case.
These people can be actual users or contacts, provided they are customer portal users.
The core of this kind of team is the case team roles configuration (Setup | Feature Settings | Service | Case Teams | Case Team Member Roles):
From here, you can define which role has which access level on the case team. You can set Private, Read Only, and Read/Write access levels. Visible in Customer Portal allows users from the customer portal to see that member.
From the case related list (you probably need to manually add this related list on the case page layout), you can select users you want to be part of your team:
The same sharing considerations apply for case teams as well.
There are some peculiarities and exceptions regarding the sharing model that you should be aware of.
The following are the peculiarities and exceptions regarding role hierarchy-based sharing:
- Contacts that are not parented to any account are inherently private, so they are visible to their owners and administrators. For this category, contact sharing rules are not applied.
- The same happens for notes and attachments with the Private flag enabled, which are visible only to the user who created them (and administrators).
- Events marked as Private are only visible to their owners and administrators.
- Role hierarchy is effective on users above them in the hierarchy, but only if they have the Read or Edit permission on the given object.
To add notes and attachments to a record, you should have read/write access to it and at least read access so that you can create activities or associate a child record with it.
If you have more than 2 million accounts and have set up account teams and territory management, take a closer look at performance to ensure that you don't have any inherently complex sharing calculations that can cause long-running transactions.
Avoid having a small number of accounts with thousands of contacts, cases, or opportunities. This is called data skew, and it can cause performance degradation. Keep this in mind and make accounts have a children ratio no greater than 1:10,000 (the less the better). This also occurs with ownership skew, which is when a few users hold ownership of thousands of objects. If this happens, make sure that the user is out of the role hierarchy (the user's role field is not filled in) or it has a higher role (for example, CEO). This simplifies sharing calculations.
A final suggestion is not to consider account hierarchies related to sharing. If a user owns a parent account, this doesn't mean they can have access to the child accounts; they aren't related to role or territory hierarchies.
The last way to share records is by aligning your company's sales territories hierarchy. This kind of sharing model is applied to account sharing and related opportunities.
At the time of writing, there are currently two different kinds of territory management:
- Original territory management
- Enterprise territory management
For the scope of the Salesforce Advanced Administrator certification, we'll describe the latter since original territory management will be retired in June 2020 (this announcement can be found at https://help.salesforce.com/articleView?id=000273181&language=en_US&type=1).
Let's dig deeper into the main concepts of territory management (TM).
The first element of TM is the territory type, which defines the kind of territories you can create. A territory type can refer to geographic zones (for example, EMEA territories) or to account segmentation (for example, utility companies). The label and description of a type should be self-explanatory so that you can avoid misunderstandings when creating territories. They won't be displayed in the hierarchy but will work pretty much like a territory guideline.
With territory type priority, you can define the priority of each territory type according to your sales strategy; for example, you can define a high priority with a value of 001 and a lower priority x with a value of 010. We suggest that you define priorities that take into account possible future changes in territory type creation (don't start by setting 001 and 002 for your only two territory types if you may have a new territory type in the next year with an intermediate value). When you create a new territory, you'll be able to choose its territory type and see its priority.
The territory object is the core of TM since it represents a group of accounts and the Salesforce users who may access those accounts. They can have parent and child territories in order to replicate your sales strategy. They are composed of users, manually assigned accounts, a forecast manager, and the rules to automatically assign accounts to this territory (pretty much like sharing rules). Depending on the territory configurations, an account can be assigned to multiple territories.
The territory model is a complete model for your organization. By using this model, you can create relationships between territories to find the best one that fits your sales strategy. You can have up to four concurrent models and only one active at a time.
The territory model is pictured in the territory hierarchy and shows the relation between territories, as shown in the following screenshot:
This page is useful if you wish to edit the hierarchy and run all the assignment rules and opportunity filters (this feature requires some custom Apex coding that's out of this scope; please refer to https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_interface_TerritoryMgmt_OpportunityTerritory2AssignmentFilter.htm for more details).
The last concept is territory model state. A model can have the following statuses:
- Planning: Previews the model before activating it.
- Active: There can be only one model in the active state.
- Archived: Only an active model can be archived. After a model becomes archived, each reference to the territory (for example, the territory field on the opportunity field) becomes blank.
- Activation failed: Something bad happened when activating (see notification email for more details).
- Archiving failed: Something bad happened in terms of the archive's state.
To enable TM, go to Setup | Feature Settings | Territories | Territory Setting and click Enable Enterprise Territory Management:
In here, you can set up default access to accounts and opportunities for each territory. In addition, you can enable contacts and case access, but only if the OWD for them is set to Private.
From the Opportunity Territory Assignment section, you can enable a more detailed filter when setting up territory management for Opportunities. The default OppTerrAssignDefaultLogicFilter Apex class can be found in the documentation (see https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_interface_TerritoryMgmt_OpportunityTerritory2AssignmentFilter.htm) and is out of scope for this book (ask a developer to help you with the setup).
Each territory has its own default values that are inherited by the parent territories above it, as shown in the following screenshot:
A territory contains assigned accounts and users.
Remember that you can create up to 1,000 territories per model for Developer Edition and Enterprise Edition organizations, while for Unlimited and Performance organizations, you can ask Salesforce support to let you have up to 99,999 territories (more than 20,000 will need a deeper inspection for approval).
The first way you can assign an account to a territory is by using rules that, based on the account's characteristics, can decide whether an account belongs to a given territory or not. These rules apply on account creation and are updated if the Territory Model is in an active state:
To create a new rule, go to the territory settings page, scroll down to the Assignment Rules Assigned to This section, and click the New button:
A rule consists of field conditions (for example, Country equals Italy, and Country equals Spain) that define the account fields to which assignment is based on, the possibility to assign the same rule to the child territories, and the active flag to enable this rule.
Can we assign to child territories? The answer is yes. First, define a generic rule that matches the different territories (for example, Country equals Italy, Country equals Spain, and Country equals Greece, which identifies southern Europe countries) that is used in the Southern Europe territory and then create a territory-specific rule in each child country for internal regions (for example, for Italy, we can have Region equals Sardinia, Region equals Sicily, and Region equals Tuscany). Finally, create specific grand-children territories depending on the postal code values you received.
Remember not to use the same rule on a child if you are already using it on a parent territory. Moreover, if your organization is using country and states picklists, use the contains operator and not the equals operator.
A territory can have up to 15 assigned rules.
You can exclude an account from the territory rules calculation by setting up the Exclude from territory assignment rules flag when updating the record (it is hidden by default on the page layout and its field-level security should be set to visible):
If you change a rule, you need to reassign the accounts that are part of the hierarchy manually by clicking the
Run Assignment Rules button at the model level or the Run Rules link at the territory level:
From the territory setting page, you can even add an account manually. This is useful when sharing rules are not enough to identify an account:
To see all the accounts related to a given territory (if you're using rules or manual assignment), click on the View Accounts button on the territory page.
Opportunities can be assigned to territories using an Apex filter (as shown earlier), but you can do this manually as well by using the Territory field and checking the Exclude from the territory assignment filter logic checkbox (they should be placed on the opportunity layout if needed):
Why is this necessary? Accounts can span multiple territories, and so there is a need to clarify where opportunities have been assigned.
Users can be associated with territories if we use the Manage Users button in the Assigned Users section of the territory setup page. Using the UI, you can assign up to 1,950 users to the territory. If you have a wider audience per territory, you should use APIs (for example, Data Loader; see the UserTerritory2Association object's details at https://developer.salesforce.com/docs/atlas.en-us.api.meta/api/sforce_api_objects_userterritory2association.htm).
You can even define territory roles for users that have been assigned to a given territory. Let's go through this now:
- To define roles, you need to switch to Salesforce Classic (at the time of writing, that is, in Spring 2019), click on Setup | Customize | User Territory Associations | Fields, and look for the Role in Territory field:
- Define your roles (here is an example):
- Then, go back (in Classic or Lightning Experience) to the territory page and go to the Assigned Users section. From here, it is possible to edit the user's role within the territory:
You can even define whether a user is a forecast manager. This option is used in opportunity forecasts so that a user can roll data up or down their territory hierarchy (and even adjust and view forecast data).
Before closing this chapter, a few words should be said on how sharing is handled in communities. You should already be aware of what Salesforce communities are, but let's provide a brief summary anyway.
Salesforce communities are a way to allow external people to interact and collaborate with your business processes. This includes customers, partners, or even employees. They are an effective way to share Salesforce data with external users and allow internal users to interact with them, reducing the service cost.
Communities are created using point and click features with tools such as the Community Builder with built-in Lightning components ready for admins to use. You can even create your own customizations using Visualforce pages or Lightning components (with your developer's help):
An organization can have multiple communities for different uses. Let's look at some examples:
- A customer community where your customers can activate self-service in order to reduce the amount of effort needed for the back office to support your products
- A partner community dedicated to your external sales partners where they can create opportunities and help your internal sales team
- An employee community for dedicated internal activities such as collaboration
Communities are the evolution of the old customer and partner portals feature.
When you create a community, you have to choose a preset template from the available list on the community creator wizard. These templates allow you to expose a certain subset of features of your CRM (Sales- or Service-oriented).
Talking about data sharing, as we saw when we talked about OWD and external sharing, a community's users have a dedicated sharing model. It can be role-based or sharing-set-based, depending on the user licenses in use.
For Partner Community, Customer Community Plus, and Lightning External Apps Plus user licenses, you can define an internal role hierarchy based on the account that each external user is associated with.
You can define how users are hierarchically related within a given account; for example, when you enable an account to be a partner account (at the time of writing, you need to switch to Classic to use the Enable as Partner button on the account record).
Go to Setup | Feature Settings | Communities | Communities Settings and set the number of partner roles (Community Role and User Settings). Let's say we want three roles. When enabling a new partner user, the user creation form displays a role picklist where you can define the role for that given user within the account's hierarchy:
These roles appear in the portal roles or portal roles and subordinates when you've defining sharing. This way, records owned by partner users can be shared using the usual sharing model:
To enable this feature, go to the Communities Settings page:
Super user access is enabled for opportunities, cases, leads, and custom objects owned by community users.
To assign this kind of permission, use the Manage External User dropdown in the contact layout in classic mode:
To assign superuser access for customer users, create a permission set (or use a previously created one) with the portal super user permission and assign it to the community users that you want to be superusers.
High-volume community users do not have roles, which removes any performance degradation related to sharing calculations with external users: they are not affected by the number of roles that are selected in the Communities Settings page.
The related user licenses are Customer Community, High Volume Customer Portal, and Authenticated Website.
But how does sharing work for high-volume users?
They only share the records they own through share groups. Note, however, that they are affected by the following sharing behaviors:
- They can access their own account and contact records with implicit sharing.
- They have read access on their account record.
- They can access a record's parent if the OWD for that record is Controlled by Parent.
- They can access a record if the OWD for that record is Public Read-Only or Public Read/Write.
- They can see other records if sharing sets have been set up.
- They cannot manually share records.
- They can't directly own an account.
- Case teams are not supported if the case owner is a high-volume user.
- They cannot be included in groups, sharing rules, account, opportunity, and case teams, Salesforce CRM content libraries, or territories.
To allow high-volume users to access records, use sharing sets. Every record you want to share with a user should have at least a user, contact, or account lookup related to the same high-volume user.
For example, you can share all the contacts related to the user's account or you can give write access to the Personal Order custom object related to the user's contacts:
Once you have created a Sharing Set, you can click on the Sharing Group Settings tab to set up who can see the high-volume user records: click on the Activate button to enable this feature (this can take a while, and an email is sent upon activation).
From here, you'll be able to specify a set of users who'll be able to access the records that have been defined in this sharing set and that are owned by high-volume users:
Record-level security is one of the most important topics when designing a successful Salesforce implementation. By completing this chapter, we have learned about the power of the Salesforce sharing model and all its possible options, from permissions to org-wide defaults, mastering sharing rules and role hierarchies, segmenting your accounts with Enterprise Territory Management, and controlling how Salesforce communities play a role in oversharing.
The Salesforce platform runs in a multi-tenant architecture, which means our Salesforce organization runs on the same server as other Salesforce organizations, which in turn means that we are all using the same resources. To keep your customization clean and performant, we need to know exactly which resources are used the most so that we don't reach our organization's limits.
In the next chapter, we will cover organization monitoring.
- You want to hide the shipping address fields of the account object from all of your sales representative users. What do you do?
- Configure field-level security to hide fields from sales representative profiles.
- Create a permission set to configure field-level security to hide fields.
- Assign no layout to the account object.
- Change the org-wide default sharing to Controlled by Parent for the Shipping Address object.
- You need the sales representative users to be able to do some service-related work. What do you do?
- Create multiple profiles and assign them to the sales representative users.
- Assign a sales representative profile and the service representative profile to the selected sales representative users.
- Use a permission set to enable specific service abilities.
- Create a new license and profile to provide the new service features.
- You want to give Delete access to the account object but not the Edit permission. How can you do this?
- Delete access requires Read and Edit OLS: this requirement makes no sense regarding OLS.
- Simply flag the Delete permission on the user's profile and unflag the Edit permission.
- Add the Modify All Data permission to the user's profile.
- Your OWD sharing on the lead object is set to Public Read/Write. How can you restrict its access to Public Read Only for a selected role?
- Create a permission set and give it the Private OLS permission on the lead object.
- You cannot restrict the record-access level except by changing the OWD settings.
- Create a sharing rule to restrict access to the Private object level for the given role.
- Enable the View All permission on the lead object for the given role.
- The OWD on the account is set to Private. An SLA custom object, which is the child of a master-detail relationship with the account object, should be able to be edited by the account's owner. How do you set up the OWD on the SLA object?
- OWD between master and child objects cannot relate.
- Set the OWD on the SLA object to Controlled by Parent .
- Set the OWD on the account object to Controlling Children.
- Set the OWD on the SLA object to Public Read/Write.
- The OWD on the Interview custom object is set to Private. HR managers should be able to see their HR reps records. How can they do this?
- Change the OWD of the Interview custom object to Public Read-Only.
- HR reps should have a role above HR managers and Grant Access Using Hierarchies for the Interview object should be flagged.
- HR reps should have a role above HR managers and Grant Access Using Hierarchies for the Interview object should not be flagged.
- HR managers should have a role above HR reps and Grant Access Using Hierarchies for the Interview object should be flagged.
- You are required to create a sharing rule to give read/write access to accounts objects owned by all the sales representatives to all the service managers (OWD on the account is Public Read). How do you do this?
- Create a criteria-based sharing rule that shares all the records owned by the sales representatives role with the sales managers role by setting the default access on the account object to Read/Write.
- Create an owner-based sharing rule that shares all the records owned by the sales representatives role with the Sales Managers role by setting the default access on the account object to Read/Write.
- Create a criteria-based sharing rule that shares all the records owned by the Service Managers role with the sales representatives role by setting the default access on the account object to Private.
- The OWD on the lead object is set to Public Read-Only. Which statements are true regarding this?
- Only the owner can manually share the record.
- The administrator can manually share the record, as well as change the lead's ownership.
- Users in the role above the current owner can see the record and edit it.
- The owner cannot change ownership of the record.
- Any owner or administrator can manually set the lead setting access to Private.
- Any owner or administrator can manually set the lead setting access to Public Read-Only.
- Any owner or administrator can manually set the lead setting access to Public Read/Write.
- You are sharing policies on the account object involves highly complex logic, such as making queries on different related child objects and external system Apex callouts. What can you do to achieve this?
- Enable a sharing model that involves criteria-based sharing rules for the child objects queries and manual sharing for the external system Apex callouts.
- Set the OWD of the account object to Private or Public Read-Only (depending on the requirements) and deliver Apex managed sharing by implementing custom Apex code with a developer of your team.
- Set the OWD of the account object to Private and allow users to use manual sharing with predefined public groups.
- Service representatives work in groups and share their accounts and related objects (such as cases or opportunities) to provide a better service experience to their customers. While owning an account, a service representative wants to give access to their team. How can they do this?
- Enable account teams and instruct the service representative on how to set up an account team and provide read/write access to case and opportunity objects.
- Enable opportunity teams and instruct the service representative on how to set up an account team and provide Read/Write access to case and account objects.
- Enable case teams and instruct the service representative on how to set up an account team and provide read/write access to account and opportunity objects.
- You can set up different team roles for opportunity and account teams.
- You can set up different team roles for case and account teams.
- You found that a lot of contacts are not related to any account. What does this mean?
- The account field on the contact object is always required.
- Unparented contacts are always considered with OWD set to Private, regardless of the OWD configuration.
- Contact sharing rules are not applied to this category of contacts.
- Unparented contacts are always considered with OWD set to Public Read-Only, no matter the OWD configuration.
- Manager users cannot see case records owned by their subordinates. How can we deal with this? The OWD on the case record is set to Private:
- The OWD should be changed to at least Public Read-Only.
- The OWD on the case records may have the Grant Access Using Hierarchies set to false.
- Check the manager profile and see if it doesn't have the case's OLS set to Read or Edit.
- Check the manager profile and see if it doesn't have the case's sharing model set to Owned by Manages.
- The OWD on the case records may have the Controlled by Parent value.
- What is data skew?
- A performance degradation issue caused by users that own thousands of records
- A performance degradation issue caused by a few accounts with thousands of related children
- A performance boost created by the defer automatic sharing rule calculations feature
- Your sales strategy depends on accounts based on the Industry field (for example, utilities, high-tech, software, and food) but also on geographic regions (such as EMEA, north-america, and asia-pacific). How can you configure your organization to match this territory configuration?
- Enable Enterprise Territory Management and define territory types based on geography and industry.
- Enable Enterprise Territory Management and define territory types based on geography only.
- Enable Enterprise Territory Management and define territory types based on industry only.
- You cannot mix territories of a different kind in your model.
- Which statements are true about Enterprise Territory Management?
- You can open access to account, contact, opportunity, and case objects but not custom objects.
- You can open access to account, contact, opportunity, case, and custom objects.
- You can assign accounts and opportunities manually to a given territory.
- An account and a related opportunity can belong to different territories at a given time.
- An account can belong to different territories at a given time.
- Your organization has a partner community that's used by sales partners so that they can create opportunities. You want all the opportunities that are used by partner users to be shared with all internal sales representatives. How can you do this?
- Enable sharing sets for your community.
- Enable share groups for your community.
- Enable partner roles on the community's setup and create sharing rules for each partner role that opens up access to sales representative users.
- Enable partner superuser access.
- Which kind of objects can be shared with high-volume users using sharing sets?
- All objects, no matter their format
- Only objects that are related to the user's account/contact/user object
- Only accounts, contacts, and users