This phase of the Salesforce Platform Governance Method focuses on the sharing and visibility capabilities of the Salesforce platform.
Overview
Phase D of the Salesforce Platform Governance Method focuses on sharing and visibility, a term that Salesforce uses to refer to providing user access to the right data. The sharing and visibility capabilities of the platform do not require that your organization takes a specific approach to data accessibility; that is down to your own data security policies. However, it is always best to follow the principle of least privilege if you are in any doubt.
The Salesforce Platform Governance Method: Phase D
“The Salesforce sharing model is an essential element in your organization's ability to provide secure application data access. Therefore, it's crucial to architect your sharing model correctly to meet your current and future data access requirements.”
—Salesforce1
Salesforce, like most applications, controls data access by starting with the user. However, Salesforce, unlike other applications, supports different types of user by way of license types.
This governance phase will primarily focus on Salesforce user types that utilize the full sharing model. Other user types, such as Chatter Free or Chatter External licenses, do not follow the standard sharing model as they do not have access to core Salesforce records (standard or custom objects) or content functionality. More important, these user types do not support roles, which is a fundamental part of the sharing solution.
Additionally, high-volume users, such as those with access to a community, also do not support the sharing model because the license types associated with these types of users—Customer Community, High Volume Customer Portal, and Authenticated Website—do not support roles. However, these license types have their own sharing model, which Salesforce administrators can leverage by creating sharing sets and share groups.
Phase D: Salesforce sharing model
Salesforce broadens the visibility of data with each service, starting at the lowest level of the organization-wide default for the object (standard or custom). Of course, if your org-wide default is set to full access for everyone, then there isn’t much point in opening the data visibility more.
Hopefully, this is where the policy of least privilege has come into play, such that your default visibility for objects, whether standard or custom, is as restrictive as possible, only opening visibility further for specific users’ job functions.
Layers of Data Sharing and Visibility
Component | Description |
|---|---|
Org-Wide Default (OWD) | Organization-wide sharing settings specify the default level of access users have to each other’s records. |
Implicit Sharing | Implicit sharing is automatic. You can neither turn it off nor turn it on—it is native to the application. In other words, implicit sharing isn’t a configurable setting; however, it’s important for your governance team to understand. |
Manual Sharing | Sometimes it’s impossible to define a consistent group of users who need access to a particular set of records. Record owners can use manual sharing to give read and edit permissions to users who don’t have access any other way. |
Role Hierarchy | A role hierarchy represents a level of data access that a user or group of users needs. |
Territory Management | When using Enterprise Territory Management, you set up a territory hierarchy that shows a model’s territory structure and serves as its main interaction points. |
Sharing Rules | Owner-based sharing rules allow for exceptions to organization-wide default settings and the role hierarchy that give additional users access to records they don’t own. |
Criteria-Based Sharing Rules | A criteria-based sharing rule is based on record values and not the record owners. |
Team Sharing | A team is a group of users who work together on an account, sales opportunity, or case. Record owners can build a team for each record that they own. |
Apex | Programmatic sharing (formally Apex-managed sharing) allows you to use code (Apex or other) to build sophisticated and dynamic sharing settings when a data access requirement cannot be met by any other means. |
Organization-wide default (OWD)
Profile-level object settings
Permission set–level object settings and permission set groups
Record ownership
Role hierarchy
Teams (accounts, case, and opportunity)
Queues
Sharing rules
Groups
Manager groups
Enterprise territory management
Sharing sets
Sharing groups
Super user access
Manual sharing
Implicit sharing
Master–detail relationship
Account relationship data sharing
External account hierarchy
Programmatic sharing (Apex)
Visualforce with Apex
Declarative Sharing – This is an area of data sharing and visibility that can be configured within the Salesforce platform without the need to write any code. This does, in fact, cover the bulk of the data sharing and visibility options.
Programmatic Sharing – This is an area of data sharing and visibility that requires programming skills, as there is coding involved. This requires a more specialized set of skills and as such will require the governance team to have those skills also.
Performance – This involves the impacts on the performance of the Salesforce platform through sharing data and changes to sharing data.
Data Security – This considers the impacts to your organization’s data security of any sharing and visibility requirements.
It is the governance team’s goal to make sure data security is maintained. Leaning on the principle of least privilege, your governance team should feel confident that the project has taken the proper steps to ensure the right amount of data is visible to users to allow them to perform their job function and no more.
Additionally, your governance team must take a longer-term view on data governance, looking at their “crystal ball” to determine whether there could be any long-term implications of the project’s sharing and visibility configuration, especially regarding enterprise objects (objects used by multiple projects, into which category Salesforce’s standard objects fall). Changes to data sharing once a significant amount of data exists in the affected objects will have performance implications.
Declarative Sharing
Phase D: sharing & visibility - declarative sharing
Most of Salesforce’s data sharing and visibility capabilities fall into the Declarative Sharing category. Your governance team is looking to understand the broader impact of any data sharing and whether there is a possibility of inadvertently giving access to data to unauthorized users.
Govern the core declarative platform features that are used to meet record-level, object, and field-sharing requirements
Organization-Wide Defaults (OWDs)
OWDs define the default behavior that each object will have regarding data visibility and sharing within the Salesforce platform. OWDs are the only core feature of the Salesforce platform that allows for restrictive access; all other features open up access. An object set to private will restrict access to the data records of that object to the owners of those records. If you created the record, you have full access to that record. If an object is set to read-only, then other users will be able to see the record but not be able do anything else.
Your governance team should look to the project team to set the OWDs for any objects that have been introduced; they should be set to the most restrictive configuration, granting extra permissions with the other features discussed in this phase.
Profile-level object settings
The governance team should review the project’s profile settings for any objects being introduced to the platform. The profile should be used to restrict objects’ data access rather than open it up. Taking this approach, data access granularity will be easier to control.
The main driver for this approach is that profiles are a broader level of access to Salesforce. Typically you would not have thousands of profiles on the Salesforce platform, but rather a small number that gives the right access to the broadest of features you want every user to have. Access to data should then be broadened via permission sets.
Permission set–level object settings
It is easy for a project team to select the most open levels of access to keep things simple. It reduces the number of test cases required to make sure everything functions correctly for every user. However, this should be challenged by your governance team.
The project should deliver permission sets for each user persona that the project expects will use the application being governed. Although data access can be configured at the profile level, it is desirable to control data visibility through a permission set, with the profile set to be as restrictive as possible. This will allow users to change profiles (as they move around your organization), while potentially maintaining the same access to the application’s data via the permission set.
Your governance team should raise concerns where a minimum number of permission sets have been proposed by your project and those permission sets offer all-or-nothing access. This will indicate that your project has not really taken the time to design data visibility against your user personas.
Record ownership
As a record owner, the user has full access to the records they have created for each object. This allows the user to read / write / transfer / delete / share a record they own.
Your governance team cannot do much about this configuration, but they should also question any project that is taking this approach as their data visibility and sharing solution, as this is mostly impractical and will lead to many manual-sharing scenarios.
Manual sharing
Manual sharing provides users access to certain types of record via the owner of that record manually sharing it with someone else.
Your governance team must highlight to the project team that if this is normal behavior for the users of their application, they should note that any previous manual sharing of the record by the owner performing the transfer will be lost. Additionally, your governance team should make it clear that the new user automatically has access to all records associated with the parent.
Govern the use of team functionality to meet business requirements
Role hierarchies
Role hierarchies grant extra permissions for those people who are managers of somebody else, which allows them to see the same data as the people they manage. This means that a manager will receive the same permissions for the record data that the person they manage has.
Your governance team should review whether inheriting permissions using role hierarchies has the desired outcome. This feature can be disabled for custom objects by unchecking the Grant Access Using Hierarchies checkbox on the OWD configuration.
Role hierarchies can have undesirable outcomes on data visibility. Take the scenario of an employee raising a case against their line manager.
Teams (accounts, case, and opportunity)
Teams allow users of the Salesforce platform to collaborate on a particular account, case, or opportunity record.
Teams can only broaden access to object records, not reduce access, and work in conjunction with sharing rules, organization-wide defaults (OWD), and other sharing methods. Team sharing is sometimes used to overcome the criteria-based sharing-rule limit (50 on the account object) or other sharing limits.
Your governance team should review the use of team sharing to uncover whether there is a hidden reason for its being proposed by the project team. If a valid use case is being proposed, then team sharing is a great way for users to collaborate temporarily. Default teams can also be configured such that users are added to a team where they regularly work with the same people.
An example of a great default team could be a Change Impact team, where a group of users can regularly collaborate around change requests handled via the case object.
Queues
Queues are a solution to more easily manage a shared workload, which is especially helpful if you have users out sick or on vacation, since if their workload is within a queue other members of that queue can pick up the work. Your governance team should pay close attention to the queue structure and hierarchy as this can cause confusion regarding data access and visibility.
Queues can be joined by specific users, roles, and public groups depending on your requirements. Queues fall under data visibility, where the object records are places in a queue for users of that queue to take ownership of the record, or the record is transferred to another queue. Role hierarchy is considered with queues, so a user that is higher in the role hierarchy than a user with access to a queue can take ownership of a record within that queue.
Your governance team is looking to be reassured that the wrong person cannot take ownership of records within a queue, or read the data within that record. Additionally, users added to a queue will be able to access all records assigned to the queue. Your governance team should look to understand how users are added to queue and what controls will be in place to control that process.
Manager groups
Manager groups can be used in manual sharing, sharing rules, and Apex-managed sharing. Manager groups can be used to share records with a management chain rather than with all managers in the same role, as with role hierarchy.
Your governance team is really looking for “accidental” exposure to data. As with most of the Salesforce platform’s capabilities, they need managing and controlling. Often, over time, some of these configurations get forgotten or abandoned, until someone sees a record they should not have.
Your governance team will need to be assured that there will be proper controls in place to maintain the manager groups. Most organizations have people come and go from roles, so the process of managing user mobility within the organization needs to extend to the Salesforce platform.
Govern list view, report folder, and dashboard folder security
List view security
Only I can see this list view.
All users can see this list view (including guest, partner, and customer portal users).
Share list view with groups of users.
The first two options are clear: either no one can see the list view or everyone can. Your governance team should challenge the need for everyone to see the list view with your project team. This may be a legitimate business requirement but may also be a simple solution to a more complex problem.
If “Grant Access Using Hierarchies” is being used, managers of group members receive access to the list view.
Managing multiple public groups with a small number of users is a burden for your Salesforce administrators.
Report folder and dashboard folder security
The Salesforce platform has a comprehensive sharing model, which extends to reports and dashboards. Reports and dashboards are stored in folders. When a folder is private to the owner, only the owner and Salesforce administrators can see the content of that folder.
Your governance team is trying to make sure that the project has considered any sharing implications with report folders and dashboard folders. Salesforce introduced enhanced folder sharing for reports and dashboards a while back, which has introduced new permissions and the way users access existing reports and dashboards.
Legacy folder sharing
Accessible by all users
Hidden from all users
Accessible only to specific public groups, roles, and role subordinates
In this case, your project team is in a similar situation to the list view security considerations from a governance perspective.
Enhanced folder Sharing
View
Edit
Manage
Each of the access levels mentioned controls what a user can and cannot do to the content of the folder. See the resource base for more detail on this topic.
From a governance perspective, your governance team is looking to see evidence that the least-privilege principle has been applied. Warning signs are clear when a project is presenting a limited number of personas that will access the application or configuration (such as one, with full access).
- Clarify communications to the users where access to their reports and dashboards may change, for example:
If two users have View All Data, but one user has Manage Dashboards, and they collaborate on a dashboard in a public folder, the user with View All Data will move to View Dashboards in Public Folders, losing the right to edit the dashboard.
If a user has Manage Dashboards in legacy folder sharing, in enhanced folder sharing they will only be able to edit their dashboards in that folder; all others will be View Access.
Govern implicit sharing within the platform
Implicit sharing
- Account and child records
Parent implicit sharing – If the user has access to a parent account record, the user will have access to the associated child records based on the account owner’s role.
Child implicit sharing – If the user has access to an account’s child record, the user will have Read-Only access to that account.
- Site and portal user sharing behavior
Contact and account record access – The portal or site user will gain Read-Only access to their account’s parent account and to all of that account’s contacts.
Service Cloud portal users – Service Cloud portal users do not have roles so are unable to access their data via role hierarchy. The user can be added to a share group to gain access to the data owned by the Service Cloud portal user.
Case access – Any user that is the contact on a case has Read and Write access on the case.
It is easy to see that data could be inadvertently exposed with implicit sharing on the Salesforce platform. Your governance team will need to understand or challenge some of the scenarios that can drive implicit sharing, especially around site and portal users. The governance team should not be particularly challenging around the business requirements themselves, just simply whether the project has thoroughly considered the configuration needed to deliver those business requirements.
Additionally, the implementation of sites and portals will need long-term management. In most cases, once the sharing configuration is initially set up it continues to work with very little interaction in the longer term; however, this can create complacency and might be something that your governance team needs to understand. People tend to come and go from organizations, and your governance team will need to be assured that the knowledge around the sharing solution is clearly documented for future team members to pick up.
Master–detail relationship
Your project team will more than likely introduce an object or two with a master–detail relationship. On many occasions, this relationship is overlooked in terms of how it impacts the data sharing model; however, it does. Your governance team should help the project team with determining whether data is being inappropriately shared because of any master–detail relationships the project has implemented.
Basically, the master–detail relationship can be viewed as a parent and child relationship, with a parent object having a fixed relationship with the child object. This means that the child cannot exist without a parent object, and so the owner field of the detail (or child) object is not available as it is automatically set to that of the parent. Additionally, this means that the detail (or child) object cannot have sharing rules, manual sharing, or queues associated with it. Although the relationship between a detail (or child) object and the master (or parent) is fixed, it is possible to re-parent a detail custom object to a different parent record if the option is configured in the master–detail relationship definition.
Your governance team should be aware that the detail (or child) object inherits the sharing and security settings of the master (or parent) object. Additionally, it is not possible to set permissions on the detail object independently of the master.
You project team should understand that the detail (or child) object records will appear on the master (or parent) object’s page layout, therefore allowing those records to be viewed. Your governance team should really be trying to determine whether this behavior is the desired outcome. Although this relationship type between two objects is quite convenient, it is harder to change later if your project team decides that details records should not always be visible to end users.
Account relationship data sharing
Account relationship data sharing rules provide granular control for account information sharing. These rules allow the sharing of objects related to the account, such as cases, opportunities, and contacts, to be shared with other accounts. This sharing model is independent of both the owner of the account and the access level granted.
Your governance team, if presented with this type of sharing rule by the project team, should try to understand the drivers behind using this type of sharing. Effectively, the project will be requesting that data associated with one account be shared with a different account. During the configuration of these rules, the project team can define the type of relationship the accounts have between them to provide more details as to why this type of sharing is required.
Your governance team will need to review the access level being used in the data sharing as well as the criteria that will drive the record sharing for the object type specified. Additionally, once a sharing rule has been created it cannot be modified; only its name can be changed. This means that if mistakes are made or changes are required, the rule will need to be deleted and recreated.
Govern the appropriate sharing design for the various community user types
With roles
Without roles
Users with roles will have a partner community license or a customer community plus license. Users with roles are impacted by any sharing that relies upon roles. Users without a role cannot be provided access to data that is driven by sharing that requires a role.
Sharing sets
Sharing sets grant site users access to any record that is associated with an account or contact that matches the user’s account or contact. Access mapping allows you to grant access to records in a sharing set. Access mappings support indirect lookups from the user. As an example, this allows you to grant site users access to all cases related to the account that is identified on the users’ contact record.
As the governing team, you must examine what records you are exposing to potential external users (i.e., site users). Sharing sets are applicable across all sites of which the user is a member. Users who have been granted access to any records via sharing sets are not influenced by the role hierarchy. There are several standard objects that can be part of a sharing set, but only custom objects with a lookup to account or contact can be part of a sharing set.
As with other sharing configurations, your governance team should pay close attention to the long-term maintenance and control of sharing sets.
Sharing groups
Sharing groups allow records owned by site users to be shared with internal and external users. This sharing solution is applicable to high-volume users, which are users with no role associated.
Your governance team will need to consider the consequences of future deactivation of any sharing groups, and how the project team intends to control and maintain these. Deactivating a sharing group removes users’ access to records.
Super user access
Super user access applies to anyone with partner community or customer community plus licenses and grants access to data owned by other partner users who have the same role or a role below them.
Super user access applies to cases, leads, custom objects, and opportunities only. However, external users will only gain access to these objects if they are exposed by their profile or sharing, and the tabs are added to the site.
As the governance team, you will need to review the project’s approach to exposing data via super user access. Your project’s role hierarchy is critical in this process. Long-term management and maintenance of this data access method will be required. The governance team needs to make sure the project team has the proper controls in place so that data is not inadvertently accessed or visible.
External account hierarchy
External account hierarchy is a feature introduced in 2020 that allows records to be shared between Community Cloud (now referred to as Experience Cloud) users in one account and Community Cloud users in a different account. This can be useful for managing subsidiaries of businesses modeled within your Salesforce org.
How many levels in the account hierarchy does the project expect to have? External account hierarchy supports up to five hierarchical levels.
How many records within the account hierarchy does the project expect to have? The external account hierarchy feature introduces a new object that should contain no more than 100,000 records per Salesforce org.
Can the account be part of more than one account hierarchy? Customer or partner accounts can only be used in one active external account hierarchy.
Does the project foresee any account merging requirements in the lifespan of the application? Accounts used in an external account hierarchy cannot be merged with another account.
Does the project expect to use account role optimization (ARO), as this is incompatible with extremal account hierarchy?
Govern the application of territory management
Territory management is best used for modeling a matrix reporting structure, where a user can report to multiple managers.
Your governance team should review the use of territory management to make sure that it has not been used as a replacement for role hierarchy. Often, territories are created to mirror role hierarchies. Additionally, your governance team should look out for any data-cleaning activities that are being used with territory assignment rules. And data clean-up should be performed by the built-in duplicate management features of the Salesforce platform, merging duplicate records or the use of Lightning Data.
Lastly, your governance team should make sure that the project has avoided any unnecessary sharing recalculations as these may have performance implications.
Programmatic Sharing
Phase D: sharing & visibility - programmatic sharing
Govern the core programmatic platform security features that have been used to meet sharing requirements
Enforcing sharing rules
Enforcing object and field permissions
Enforcing SOQL data filtering
Class security
Apex-managed sharing
Enforcing sharing rules
Apex normally runs in a system context, which basically means that the current user’s permissions are not considered during the execution of the Apex code (except for code that is executed with executeAnonymous). However, sharing rules are not always enforced. Apex classes declared with the without sharing keyword will not enforce sharing rules.
If this keyword is used by your project team in its Apex development, your governance team should make sure that data is not inadvertently being exposed where it would normally be hidden from users by permissions, field-level security, or organization-wide defaults.
Your governance team should also check that a class declared as with sharing is not calling a different class using without sharing.
Enforcing object and field permissions
Apex does not enforce object and field permissions as standard. If object and field permissions are critical aspects of your project’s security model, your governance team should challenge the project to overcome this default behavior.
Your project team can enforce object and field permissions by using the sObject’s describe result method. Your project should consider using Schema.DescribeSobjectResult and Schema.DescribeFieldResult to understand whether the current user has read, create, or update access to an sObject or an sObject’s fields. Your governance team should look for evidence that this extra code has been implemented correctly.
Enforcing SOQL data filtering
Another area of Apex that can create data access and visibility leakage is SOQL. The use of SOQL within Apex code is common practice. However, your governance team should look to the project team to make sure that any object- and field-level permissions are adhered to.
Your governance team should also look to the project team to enforce security for SOQL statements using the stripInaccessible method. This method will remove any fields that do not meet the permissions of the current user.
Additionally, SOQL queries can be made security aware by using the WITH SECURITY_ENFORCED clause.
As there are restrictions around the usage of both of these features, it is more than likely that your governance team will see both in action across Apex that must provide user-level data access that correctly adheres to the user’s permissions.
Class security
A project can control which users can execute methods on Apex classes (does not include triggers) using profiles and permissions. This could be an additional level of security control that can restrict access to sensitive methods, such as a method that calculates commission payments. Although this is in the control of the project team because it will be driven by business requirements, your governance team can discuss this feature as an additional way of securing sensitive functions developed in Apex.
Apex-managed sharing
Apex sharing (more often referred to as programmatic sharing) allows the use of code to build sophisticated sharing models that might not be possible using declarative solutions.
As part of your governance, your team should make sure that the project team is providing the relevant Apex classes for recalculating sharing. These Apex classes will be executed every time a custom object’s organization-wide default access level is changed.
As programmatic sharing falls within Phase F of the Salesforce Platform Governance Method, your governance team should flag the project’s application as requiring further governance, as all Apex programming should be governed consistently.
The Apex sharing recalculation class must implement the Database.Batchable interface. Your governance team now knows that Phase F must pay attention to the best practices for developing batch Apex. Additionally, your governance team should also expect Phase I to be used to govern the project’s development life cycle, specifically around source control, development standards, testing, and deployment of Apex code.
As Phase F will no doubt highlight, your project team should also deliver all the relevant Apex tests and make sure that the APEX class used for sharing recalculation is associated with the custom object via the custom object’s management settings.
One of the challenges facing your governance team will be determining whether programmatic sharing has been used appropriately. As mentioned in Phase A of the Salesforce Platform Governance Method, some resources prefer to develop solutions using code rather than explore pre-existing platform capabilities. It is the role of the governance team to make sure this does not happen.
Your governance team should always challenge your projects if programmatic sharing has been used when a declarative solution could have been. This is because the programmatic solution inevitably adds more complexity to your project’s application, increases the maintenance overheads, and drives a different model into your platform resourcing requirements for operational support.
The obvious is that no other declarative sharing solution is available to meet the data sharing needs of the project.
Poor performance has been experienced using declarative sharing solutions, which can occur when your project expects very large data volumes; you may also experience this for applications that have been in use for a while.
You require team functionality for your project’s custom objects.
Your project expects data access to be dictated by an external source, such as an external system to which you are integrating.
Govern the security risks in programmatic customizations relative to data visibility, focus on difference in capabilities between programmatic sharing for standard vs. custom objects
The Salesforce platform has several security defenses built into the Lightning platform; however, just like any other platform, careless programming can bypass these defenses, thus exposing applications to security risks.
As mentioned previously, it is easy for Apex code to see the complete data available on the Salesforce platform rather than just the data that should be visible to the current user. This is not something the project team really has to concern itself with when using declarative sharing features. Your governance team will need to grasp the holistic view of the sharing solutions being proposed by your project team so as to provide a full assessment of the security implications of the project’s choices.
Your project team should also pay attention to the differences in sharing standard versus sharing custom object records using programmatic sharing. Standard objects, such as Account, Contact, and so on, do not support the Apex Sharing Reason. For this reason, standard objects use the RowCause of “Manual” by default. Shares with this condition are removed when record ownership changes. Therefore, users may find they lose access to data from standard objects where programmatic sharing was used and the record ownership has changed. This is not the case for custom objects.
Performance
Phase D: sharing & visibility - performance
Govern whether the solution is scalable to and maintainable at enterprise levels
One of the primary concerns for your governance team will be the performance of the Salesforce platform. Often, the Salesforce platform becomes a business-critical platform that is used by thousands of people every day within your organization. If that is not the case today, it may well be the case in the future.
Changes to sharing data can have a significant impact on the performance of the Salesforce platform.
We have all experienced that situation where a change is made to a sharing rule that then triggers a recalculation that impacts the platform for days. Plan changes carefully and make sure the scale of the change is well understood, and consider the number of records and the number of users that are impacted by the change.
Your governance team should take time to understand the changes your project intends to deploy into your Salesforce platform. For a new application, one that has never been deployed before, you will not have pre-existing data. Sharing rules, which are hopefully part of the deployment package that the project is constructing, will have limited impact. However, if you have had a Salesforce implementation for some time, you may find that your project is leveraging enterprise objects (standard or custom). Alternatively, your project may be deploying a change to an existing application that has been in use for several years and has vast amounts of data.
Whether any large quantities of data are to be loaded after any sharing rules have already been created
Limit updates to account relationship data sharing rules that are being used by multiple account relationships. Recalculating account relationship data sharing rules for many records can take some time. If updates to active account relationship data sharing rules are necessary, space them out to avoid performance issues. Also, shared data may not be immediately available after you make the updates.
Avoid bulk contact reparenting operations.
For optimal data processing, position users who own many records at the top of an external role hierarchy.
Salesforce has a recommended limit of 50 million records for custom objects.
If possible, load your data before you set up account relationship data sharing rules. Loading data after you create account relationships and account relationship data sharing rules activates the sharing rules. If it is necessary to load data after account relationship data sharing rules have been created, load no more than 1 million records per day.
Salesforce automatically recalculates sharing for all records on an object when its organization-wide sharing default access level changes. The recalculation adds managed sharing when appropriate.
Every time a custom object’s organization-wide sharing default access level is updated, any Apex recalculation classes defined for associated custom objects are also executed.
Where bulk changes are to be made, such as role hierarchy changes, has the project considered deferring automatic sharing recalculation?
However, even for “green-field” deployments of applications, your governance team should take a long-term view of data sharing, considering any data volume estimates presented by the project team during Phase B of the Salesforce Platform Governance Method.
Data Security
Phase D: sharing & visibility - data security
Govern any specific secured data implementation on the Salesforce platform
Your governance team will need to understand whether the project has any specific data protection requirements. These are generally business dependent, but normally fall into the category of data requiring additional protection for some reason. The reason could be regulatory or just specific to your business.
If your project has specific requirements to secure data for any reason, your governance team will need to understand how that data protection will be implemented so that they can determine whether that requirement is in fact fully met.
The project should provide personas for the usage of the application they are building or the configuration they are delivering. These personas should provide the levels of data security required. An example of business-type data that may require additional levels of protection could be credit card numbers. The project may provide several personas that can view a lot of data, but only certain personas are trusted to see the customer’s credit card number. Additionally, Salesforce administrators, typically the custodians of the Salesforce platform, may not be allowed to see this particular information.
Govern the use of “classic” encryption fields in the Salesforce platform and the limitations that need to be taken into consideration
The Salesforce platform’s classic field encryption provides a convenient solution to protecting data within fields that your project wants to keep private. As previously mentioned, the use of a credit card number field might fall into this category. Only specific users will normally have access to a customer’s credit card number. It is not something that every user should be able to see.
If a user with the View Encrypted Data permission grants login access to another user, that user will see encrypted fields in plain text.
Encrypted fields are limited to 175 characters.
Encrypted fields are editable regardless of whether the user has the View Encrypted Data permission. The project must use validation rules, field-level security, or page layouts to prevent this.
Encrypted data fields can still be used in validation rules and Apex regardless of whether the user has the View Encrypted Data permission.
Existing custom fields cannot be converted into encrypted fields, nor can encrypted fields be converted into another data type.
The project should only use encrypted custom fields when the business requires an extra level of security due to processing overheads and search-related limitations.
Method
Declarative Sharing
Programmatic Sharing
Performance
Data Security
Approach
This phase is focused on governing the data sharing and visibility aspects of an application or configuration. In some part, these will be driven by security policies already in place within your organization. If that is not the case, these security policies may be a deliverable of the project itself, effectively setting the standards for future application development.
As this phase may contain Apex source code, your governance team will inform the project team that they are subject to subsequent governance phases if Apex source code is part of the project’s application or configuration.
Your governance team should not seek to reject any sharing the project deems necessary to deliver the business requirements, but rather should explore with the project team that the correct platform feature has been used and that consideration has been made regarding the impacts of data sharing on the wider data security of the platform.
Where enterprise objects have been impacted in the sharing and visibility solution, the governance team should be confident that a wider impact analysis has taken place on the projects impacted by the changes being proposed. Remember that enterprise objects are standard or custom objects in use by more than one project or application within your organization.
Inputs
Application configuration and source (or the repository in the instance of using a source control system) where appropriate
User personas, detailing permissions and data sharing and visibility requirements
Security policy (if defined by the project)
Clear definitions around sensitive data
Steps
The steps to govern the sharing and visibility phase will help the project team understand how users will gain access to the data held within the Salesforce platform. The governance team should ensure that the project team has used a least-privilege principle for data access and be assured that data security is maintained.
Declarative Sharing
- 1.
Govern the core declarative platform features that are used to meet record-level, object, and field sharing requirements.
- 2.
Govern the use of team functionality to meet business requirements.
- 3.
Govern list view, report folder, and dashboard folder security.
- 4.
Govern implicit sharing within the platform.
- 5.
Govern the appropriate sharing design for the various community user types.
- 6.
Govern the application of territory management.
Programmatic Sharing
- 1.
Govern the core programmatic platform security features that have been used to meet sharing requirements.
- 2.
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
- 1.
Govern that the solution is scalable to and maintainable at enterprise levels.
Data Security
- 1.
Govern any specific secured data implementation on the Salesforce platform.
- 2.
Govern the use of “classic” encryption fields in the Salesforce platform and the limitations that need to be taken into consideration.
Outputs
Not Applicable – This phase in the Salesforce Platform Governance Method is not applicable to the project.
Remediate – The governance team requests that the project team remediates its design to accommodate the issues raised during the governance review.
Pass – The governance team has found no issues or concerns with the project’s proposal and therefore the project has passed this governance phase.
Review – The governance team has found the inputs cannot be objectively measured and therefore a subjective view has been made, which will lead to a discussion with the project team to reach consensus. Although undesirable, this could be a consequence of unclear standards/policies.
Scenario
Govern the core declarative platform features that are used to meet record-level, object, and field sharing requirements
Returning to our fictitious company, Bright Sound Guitars Ltd., you may recall Hanna, the project’s architect. Hanna wants to provide an overview of the sharing model she wants to put in place. Hanna wants her users to have access to as much data as possible, as she feels that the more data the users can see, the easier their jobs will be.
Standard User – Someone who has access to all data and can see and do everything
Administration User – Someone who is like the Standard User but is known as the administrator.
Hanna highlights that this is really the starting position, and she doesn’t really have a good handle on exactly the types of users her project’s application will have. She wants to allow the application to “bed in” for a few months before really tackling data visibility and sharing.
- Given that Bright Sound Guitars is operating a least-privilege principle to data access, the governance team knows that the business area that Hanna’s application is going to be deployed to has a very good role hierarchy in place. The team suggests that Hanna review her personas along the lines of the following:
Contact Agent – Users have access to the data records they own. Users can manually share data records with other users where required, but this must be supported with an approval process from their line manager.
Team Lead – Users have access to their own records and by using the role hierarchy can access the data of the contact agent that reports to them.
Department Lead – Using the role hierarchy, the department lead can see the entire department’s data.
The governance team would like to see sharing automated, and express that manual sharing can lead to a lot of overhead in terms of knowing who can see what. They feel that with a little more investigation, Hanna will see a pattern that could drive a sharing rule.
Hanna likes what she is hearing and takes the advice away to work with the business to understand more around the personas they have in their department and what data those personas can and cannot see. She feels like she understands more about the use of roles and how that could help expose data to broader user groups without the complexity of manually sharing data. The sharing rule is a great idea, and she already has an idea as to why one contact agent may involve another.
Summary
There is no doubt that the Salesforce platform offers a magnitude of sharing capabilities. Some might say it is too flexible. It is easy to see that with all the different features available to share data and broaden data visibility a Salesforce platform could become quite complex to manage.
The key principle to remember is the principle of least privilege. Taking that principle, you must work through the options to deliver the data visibility and sharing model that your project requires. Pay close attention to limitations that each feature has, as some may not be an issue from the offset, but may become an issue further in the lifespan of the project.
Consider all the consequences that are a result of sharing. Keep a holistic mindset, especially around the use of sites and communities (now referred to as Experience Cloud).