This chapter contains the resources required to govern Phase D of the Salesforce Platform Governance Method. The approach we have taken is to assemble the most relevant resources that align with the corresponding governance method. Since you’ve been working through the book and using these resources, you’ll know that although we have tried to cover all the major areas relating to this topic, completing your own research in addition to examining the resources we have provided will really set you up for success.
You do not need to use this resource base as a strict method or process. The idea is that this will give you a good indication of what you should be taking into consideration. The expectation is that you will use this as a guide and then build upon it as you navigate the Salesforce ecosystem.
Guidelines and Best Practices
This section contains guidance and best practices available from Salesforce, as well as other resources that we have determined will be valuable. This section should serve to provide a good set of guidelines that can be reviewed by anyone delivering the governance function within your organization.
We know there is an infinite number of resources available on the Web, and although some are better than others, this resource base will provide you with a good selection of resources that we recommend you review. As per all the resource base documentation in this book, providing the complete technical definition for every aspect of sharing and visibility is not the objective; if it were, I think we could devote the entire book to this topic alone. The resource base is divided into two main sections: the resources themselves and related standards, and finally the supporting governance checklist.
As is the case with all the resource base chapters in this book, the links to the resources will be managed in the Salesforce Platform Governance Method GitHub account. The URL for this account is as follows: github.com/salesforceplatformgovernancemethod.
Sharing & Visibility
Given that you have arrived at the resource base, we must assume that you have been reading the content in the governance method described in Chapter 5, “Sharing & Visibility.” To get you on the right track, we have offered Table 15-1 to provide resource links to the content that’s discussed.
I think it’s fair to say that the importance of how we secure our data cannot be understated in any context. Data is at the center of everything we do. If we cannot secure our data appropriately, then the ramifications for our business could be catastrophic. As a business, we have a duty of care for our customers to ensure that business data is secured and only shared with those that need to access it. In Chapter 5, the concept of least privilege was discussed; this is a security principle that all CISOs (Chief Information Security Officer) and security organizations within an enterprise will be expecting to be implemented as standard policy. This ensures that data is only shared when there is a specific requirement to do so and with specific resources, be it user (internal or external), other business processes, systems, or tools.
Internal users are the users within your organization who consume a Salesforce license and log in directly to the Salesforce platform. External users are the Experience Cloud customer users or users who do not log in directly to the platform.
The Salesforce sharing model has been specifically designed to give you a flexible and robust framework via which to share platform data. Org-wide defaults, role hierarchy, implicit sharing, manual sharing, programmatic sharing, field-level sharing, teams, profiles, permission sets, sharing rules, and sharing sets are all sharing methods you can use within the Salesforce platform to share records with your users. However, you must be sure that you are applying the correct sharing method and ensure that you are not inadvertently sharing a record with users to whom you did not intend to give access. In this case you need to be aware of the relationship types you opt for in your data model, as this could impact how records are shared. For example, where you have a master–detail relationship, detail records will always inherit the security settings and permissions from their parent. Therefore, if you share the master record, the detail or child records will also be shared.
In all scenarios, it’s best practice to plan your sharing model carefully. Decisions you make on how to share and give access to your Salesforce resources must be carefully considered, as you want to make sure that the sharing choices made will enable business success not just for your initial implementation, but also for future data access. The resources discussed here will help you on this journey. Reviewing all the available sharing methods and having a good understanding of the types of sharing available, along with sharing use cases, will set you on the right track and should also help to make the governance process far simpler. Being able to explain why a specific sharing method is used over another will be a crucial aspect of the governance and sign-off process that you will need to present to the governance control board.
Declarative Sharing Resources
Sharing & Visibility – Declarative Resources
Artifact | GitHub Ref | Description |
|---|---|---|
Salesforce Security Guide | Salesforce Security Guide | This is the definitive guide to the Salesforce platform security. This guide covers the basics of Salesforce security, from health check, authentication, data access and sharing to shield encryption and real-time monitoring. |
A Guide to Sharing Architecture | Salesforce Sharing Architecture | For lighter reading, you may wish to review the Salesforce resource titled “A Guide to Sharing Architecture.” This guide provides all the concepts of sharing in a more concise package. |
Control Who Sees What | Who Sees What | If you are new to the subject of Salesforce security, we recommend this resource, as it provides a good overview of the various sharing methods available in Salesforce. Additionally, the video series for Who Sees provides a demonstrative aspect of how the basics of Salesforce sharing works. |
Who Can See My File? | Who Can See My File | There are different ways that files can be shared in Salesforce: private to you, privately shared, or visible to your entire company. This resource helps you to learn how to identify file-sharing settings and how to change them. |
Organization-Wide Sharing Defaults | Org-Wide Defaults | In Salesforce in Setup / Sharing Settings, you will find the org-wide defaults. This provides you with the default security definition for your org. Essentially, the OWDs (org-wide defaults) define the level of access that the users in your org have to each other’s data. It is important to set the most restrictive security here. Then use the sharing methods to open access to data as per the data access requirements for your business. |
Profiles | User Profiles | In Salesforce we assign users to profiles; in fact we have to. When you create a new user, you must also assign a profile. Profiles are used to control how users access objects. We also use profiles to manage several different facets of access that define what users can do in applications. This resource will give you a deeper understanding of how profiles are used to control what users can do and also how they are used to control the user’s environment: password policies, IP login hours, field-level security, and access to page layouts, to name a few. |
Permission Sets | Permission Sets | Permission sets are used as an extension to profiles. Remember that users can only be assigned to a single profile. With permission sets you can extend the access configuration and assign the permission set to a group of users. Additionally, you can assign multiple permission sets to a user, giving you a very flexible way to provide additional access. There are also several different types of permission sets, so depending on your requirement, a specific permission set may be more suitable than another. |
Developers Blog: Behind the Scenes of Record Ownership in Salesforce | Record Ownership | For a detailed and comprehensive view on how record ownership works within the Salesforce platform, review this resource. Here the record sharing architecture is described in enough detail to be easily understood. It also describes the process or sequence of events that occurs when a record is accessed. |
Custom Permissions | Custom Permissions | In Salesforce, you may have a special use case where you have to assign a permission to a user in support of your business process or app that is custom in nature. In other words, your requirement cannot be achieved with standard permission built-in options. Review this resource to learn more about custom permissions and how they can be used. |
Manual Sharing | Manual Sharing | Manual sharing is really what it sounds like. With manual sharing a user can share a record that they own, or a user can share a record where the user sharing is higher in the role hierarchy than the owner of the record. This method satisfies a sharing requirement that is ad hoc, or when a user wishes to share a specific record. |
Controlling Access Using Hierarchies | Role Hierarchy | In Salesforce you can control access to records using hierarchies that apply to roles. Using this method, you can provide users access to records that they do not own. Essentially, the configuration “Grant Access Using Hierarchies” will grant access to records owned by all subordinates in the hierarchy. This resource explains how hierarchies work, how to set them up, and how to use them successfully. |
Developers Blog: Locking Down Record Access in Salesforce | Locking Down Record Access in Salesforce | Following on from the previous resource, this resource provides further context on the sharing configuration “Grant Access Using Hierarchies.” |
Team Resources | Salesforce Teams | Salesforce provides you the ability to organize users that work together on a sales opportunity, account record or case record. As a record owner, you can assemble a team that can work collaboratively on specific records. This resource covers each use case and the associated considerations that you should review. For example, you can use opportunity teams, where users work together and mange how revenue credit is shared among the team members using opportunity splits. |
Queue Resource | Salesforce Queues | In Salesforce, every record must be owned by either a user or a queue. With queues, you can organize work into a manageable distribution to users who are members of the queue. As an example, you may wish to set up queues as part of an omni-channel configuration to manage how case records are distributed in a service support team. |
Sharing Records with Manager Groups | Manager Groups | Manager groups allow you to control how you share records with managers in the management chain in the role hierarchy. You may only want specific managers to be able to see your record instead of the default. |
Enhanced Folder Sharing for Reports and Dashboards | Enhanced Folder Sharing | If you have a requirement to have more granular sharing options for reports and dashboards, then enable this feature. Review this resource to understand the differences between legacy and enhanced sharing and to learn what happens when enabled. There are also some practical examples of how enhanced folder sharing works. |
Implicit Sharing | Implicit Sharing | When we refer to implicit sharing, we are referring to sharing behaviors that are built into the platform and require no additional configuration by your awesome admins. For example, if you have access to a parent account record, then you will also by default have access to the account’s child records, such as cases or opportunities. Use these resources to understand how implicit sharing works and the associated implications for parent–child data skew, as an example. |
Object Relationships Overview | Salesforce Object Relationships and Sharing | In Salesforce, there are several relationship types that can be configured to control how objects relate to each other. Master–detail, lookup, and many-to-many are all examples of how you can model relationships in the platform. Using these resources will serve to reaffirm your understanding of the sharing behavior when considering the object relationship you have configured. |
Viewing Which Users Have Access to Your Records in Lightning Experience | Sharing Hierarchy | Since the Summer 2021 release there is a new feature that you can use to easily view which users have access to your records and, more important, why. For accounts, opportunities, cases, contacts, and custom objects, you now have a new menu option in the record’s list view action menu to view “Sharing Hierarchy” details. What’s great about this is that you can also see the reason why the record was shared, the relationship, and the level of access. |
Set Up Sharing Sets | Sharing Sets | With sharing sets you can share any record with your Experience site users where the account or contact matches that of the user or via an access mapping defined in a sharing set. Access mappings support indirect lookups from the end user and target record to the account or contact object. Sharing sets provide a useful way to share records without exposing records that you do not intend to share. This resource covers this feature in detail. |
Use Share Groups to Share Records Owned by High-Volume Experience Cloud Site Users | Sharing Groups | Use sharing groups to share records that are owned by your high-volume Experience site users with authenticated internal and external users. Use this resource to learn more about sharing groups and how to set them up. |
Super User Access | Super User Access | With Experience sites, you may want to provide elevated access to your partner users. When you grant super user access, you give the partner user permission to view other users’ data as long as they have the same role (or higher) in the partner role hierarchy. This level of access does not respect sharing rules or org-wide defaults. Review this resource to learn more about super user access and how it could be used to open record access for your partner users. |
Configure an External Account Hierarchy | External Account Hierarchy | Following on from the previous resource, with partner or customer Experience sites you can create an external account hierarchy that gives you similar functionality to role hierarchies, but for your external users. (You need the correct licenses!) There are some limitations for this sharing feature, and this resource covers them in detail. Review this resource if you are planning to use this feature to share records with external users. There is also a Trailhead that’s an excellent resource as you build the functionality in a safe environment. |
Role and Territory Sharing Groups | Territory Management | First, you need to understand what territories are in the context of Salesforce. Simply put, we use sales territories to define how sales teams manage their accounts (and related contacts and opportunities) across our business or business regions, for example. When we configure territories, we can use them to control how access to these objects is set for users in the territory. Review this resource to learn more about how this works. |
Programmatic Sharing
Sharing & Visibility – Programmatic Sharing Resources
Artifact | GitHub Ref | Description |
|---|---|---|
Apex Developer Guide: Apex Security and Sharing | Apex Security and Sharing | All the security resources are included in this guide. If you are looking to review the entire section, then start here. Even if you are not a developer, it’s good practice to be aware of the sharing capability as when it comes to governance and reviewing whether the development function has adhered to best practice, this guide will give you the understanding you need to question if your code is using these security features. |
Enforcing Sharing Rules | Apex Sharing – Enforcing Sharing Rules | This resource covers the implications of using “with sharing” and “without sharing” in your Apex classes to define security. Apex will by default have full access to the Salesforce database unless the security context is specified in the declaration. From a governance perspective, you do not want to expose data to a user that they do not and should not have access to. This resource explains the differences and security implications. |
Enforcing Object and Field Permissions | Apex Sharing – Enforce Object and Field Permissions | This resource is a must read as it explains how DML (Data Manipulation Language) actions (those associated with creating, updating, and deleting database records) can be incorporated with security checks. Basically, the DML action will not execute if the user does not have the required permission to make the change. This resource explains how this can be achieved by calling the sObject describe result methods. |
Enforce Security With the StripInaccessible Method / Filter SOQL Queries Using WITH SECURITY_ENFORCED | Apex Sharing – SOQL Data Filtering | These resources delve further into the security features available to developers in Apex to enforce security on the platform. In this resource, stripInaccessible and WITH SECURITY_ENFORCED are explained with practical examples of how they are used to enforce the sharing rules for users of the platform. |
Class Security | Apex Sharing – Class Security | Depending on your use case, it may be appropriate to control which users can execute Apex classes. This resource explains how to configure this using either profiles or permission sets. |
Understanding Apex Managed Sharing | Apex Sharing – Apex Managed Sharing | This resource covers Apex managed sharing. At this point, we probably have a good grasp of the declarative sharing capabilities of the platform. But how this works in the context of code is an important part of the sharing model in Salesforce. This resource covers sharing broadly, how to share a record in Apex, and considerations for recalculating Apex managed sharing. |
Sharing & Performance Impacts
Sharing & Visibility – Performance Sharing Resources
Artifact | GitHub Ref | Description |
|---|---|---|
Defer Sharing Calculations | Defer Sharing Calculations | When performing many configuration changes to groups, account ownership / reparenting, or any change that involves changing users’ access rights, sharing recalculations will be inevitable. You can, however, defer sharing calculations. This means temporarily disabling sharing calculations until a more convenient time. Normally this would be when the sharing operation or change being performed is completed. Re-enabling sharing calculations will then process all the updates in the background until complete. |
Speed Up Recalculation of Sharing Rules | Sharing rule Recalculation | Aside from deferring sharing calculations, if you run into problems with the impact that sharing recalculation poses then you can look at the other options that are available to you that may help to lessen the effect of changes on your org. You can either opt to manually run the recalculation process via the setup interface, or have asynchronous parallel recalculation switched on for your org. This option runs the recalculation process in the background, and you can track progress via the Background Jobs interface in Setup. |
Data Security
Sharing & Visibility – Data Security Resources
Artifact | GitHub Ref | Description |
|---|---|---|
Strengthen Your Data’s Security with Shield Platform Encryption | Shield Platform Encryption | Data encryption is a business and, in some cases, regulatory imperative in today’s enterprise environment. Modern business operational standards demand that any user’s private data that is stored in a remote platform, be it cloud hosted or on-premises, should always be securely stored and therefore not be susceptible to unauthorized access. In addition, data should be encrypted wherever possible during transit and at rest. The Salesforce solution for encrypting data at rest is Shield Platform Encryption. There is a classic-based alternative, but this resource covers platform encryption in its entirety. |
Classic vs. Platform Encryption | Encryption Types – Classic vs. Platform Encryption | Salesforce Platform Encryption is a feature add-on product and therefore requires an additional license. Classic encryption is an option but does not provide the same level of functionality. This resource provides the information required to understand the differences between the two encryption methods on offer from the Salesforce platform. |
Phase D Standards
As we have read, in this chapter the main message is how to use the platform to secure business and user data. This is an important part of your architecture and solution design. Security breeds consumer trust, and trust will enable your business to grow and therefore increase your customer base. Exposing users’ data inappropriately or not securing data sufficiently could have a detrimental impact to user adoption of your services, and ultimately you’ll see your market share diminish over time. Therefore, the importance of data security cannot be understated in any capacity.
In support of the governance process, you may need to find simpler ways to show the sharing model for your application than showing your team the platform interface itself. Depending on the audience, a simple spreadsheet that defines the sharing (CRUD) assigned to a profile / permission set for each object should be sufficient way to convey how permissions have been applied. Similarly, it’s good practice to document the role hierarchy in the same way.
Other standards to consider are the naming standards used for your permission sets, groups, and roles. It’s good practice to use names that make it easy to identify the application and project to which the sharing element is related. In addition to documenting the sharing model as described, making sure that any additional custom security you enable is named appropriately will help other admins find and understand what the security group or permission set is for. The description field should always be used and give a full description detailing what the permission set or group is intended for.
Other naming considerations are as follows: single-letter names are not acceptable; app names should use CapitalizedCamelCase.
In fact, this is just an example of what is advised in the “Naming Conventions” link in Table 12-1 from the Phase A resource base.
Underscores should not be used for any variable name, object name, class name, or method name except as an application prefix. Overriding standard tabs for object and standard names should not be allowed without first seeking approval from your central governance team.
Good | Bad |
|---|---|
Permission Sets <PROJ_Name> Or <PROFILE_NAME> <Purpose> Example: Standard User Access to <Custom Object> | UserAccess |
Group <Business_Process> Retail User Group | Grp1 |
Checklists
Governance Step | |
|---|---|
Declarative Sharing | Pass / Fail |
Govern the core declarative platform features that are used to meet record-level, object, and field sharing requirements | |
Govern the use of team functionality to meet business requirements | |
Govern list view, report folder, and dashboard folder security | |
Govern implicit sharing within the platform | |
Govern the appropriate sharing design for the various community user types | |
Govern the application of territory management | |
Programmatic Sharing | Pass/Fail |
Govern the core programmatic platform security features that have been used to meet sharing requirements | |
Govern the security risks in programmatic customizations relative to data visibility; focus on difference in capabilities between programmatic sharing for standard vs. custom objects | |
Performance | Pass/Fail |
Govern that the solution is scalable and maintainable to enterprise levels | |
Data Security | Pass/Fail |
Govern any specific secured data implementation on the Salesforce platform | |