Anyone who’s been working with the Salesforce platform will be aware of at least a handful of ways to share a Salesforce record – certainly anyone who has studied for the Certified Administrator exam!
There are quite a few ways to share record access in Salesforce, which may lead you to wonder why there are so many mechanisms you could use. Truth be told, Salesforce can cater for even the most complex sharing use case, no matter how granular sharing frameworks need to be. Salesforce professionals have great control over how to design their org privacy, and a lot of options to choose from.
How Can You Share a Record in Salesforce?
First, what do we mean when we say “share a record”? “Share” could have a few different interpretations, depending on who you ask. It could mean:
- Granting access to records for Salesforce standard/custom objects (which a Salesforce Admin controls).
- Granting access to records either based on record criteria or by choice, i.e. on a case-by-case basis (admins and users with permission).
- Drawing attention to a record (which any end user with access to the record can do).
- Sharing partial information from the record.
Before we dive in, here’s the full list of items this article will be covering:
- Account, Opportunity, and Case Teams
- Apex-Based Record Sharing
- Chatter
- Dashboard “Viewing As”
- Data Category Groups
- Delegated Group (Delegated Administrator)
- Enterprise Territory Management
- External Account Hierarchies
- Flow-Based Record Sharing
- Manager Groups
- Manual Sharing
- Master-Detail Relationships
- Org-Wide Default
- Permission Set Groups
- Permission Sets
- Personal Groups
- Print a Dashboard
- Profile
- Public Groups
- Record Owners
- Report Subscribe
- Role Hierarchy
- Salesforce Queues
- Screen Flow
- Share a Record via Slack
- Share Group
- Sharing Rules (use Roles and Public Groups)
- Sharing Sets (Site-Specific Sharing)
- Super User Access
How Admins Can Share Records in Salesforce (Access Objects and Records)
Salesforce Admins sit at the ‘control center’ where they use a combination of permissions (Create, Read, Edit, Delete, and field-level security) to make object access spot on for what their users should be able to view and edit. The way data relationships are formed can also grant access to additional records as a result.
This framework can get very granular, which is why a skilled Salesforce Admin is so valuable, not only to keep track, but also to optimize.
- Profile: Control what users can do in your Salesforce org. This can be referred to as CRED (Create, Read, Edit, Delete). For example, you may want some users in your org to read and edit Leads, but not delete them. CRED enables you to mix and match what a specific user can do with each object.
- Permission Sets: Consider these add-ons for profiles. They offer flexibility in how you add certain permissions (objects, field-level security, page layouts, record types, apps, tabs) to certain users – almost like you are tagging an individual user or a small subset of users, such as Super Users. Even more so, permission sets are the future – the recommended best practice is to leverage a baseline profile with permission sets, which open up access as needed.
- Permission Set Groups: These allow permission sets to be grouped together and assigned to users. Even more so, they also introduce the concept of Muting Permission Sets, which allows you to forget about altering Permission Sets directly, but rather turn off only certain permissions for the given group.
- Org-Wide Defaults (OWD): The baseline visibility set for each object in your org. Within the Sharing Settings page in Setup, you can determine the data visibility for your users and decide if access through role hierarchy is enabled, opening up access to Salesforce records.
- Role Hierarchy: This enables you to supersede (push past) the OWD, further opening up access to Salesforce records. It may help to think of roles being arranged into a hierarchy, following how users relate to each other in a hierarchy, e.g. the VP of Sales is above the Sales Managers. This way, managers will be able to have their access extended to their team’s records.
- Master-Detail Relationships: A strongly coupled relationship that allows the parent record to control child record attributes, such as sharing and visibility. Whichever security setting you chose for the parent record, the child record inherits.
How to Share a Record (By Criteria or Choice)
This section applies to capabilities that grant access to records either based on record criteria or by choice (i.e. on a case-by-case basis). Both Salesforce Admins and end users with the correct permissions can do this.
- Record Owners: Every record in Salesforce has an owner, which can be a specific user (or queue – featured later). Record ownership ‘stamps’ the name of the user responsible/owns the relationship clearly on the record. In terms of additional rights, becoming a record owner enables the user to share records. As you will realize reading this list, record owners are foundational to many of the other record sharing frameworks.
- Sharing Rules: This enables you to supersede (push past) the OWD, further opening up access to Salesforce records (similar to the role hierarchy, but not only vertically). You can create rules to open up access to records by either who owns or by the criteria of the record itself.
- Manual Sharing: Enables you to grant access to the specific record. There are important considerations to this type of sharing.
- Delegated Group (Delegated Administrator): Members of the Delegated Group are able to log in as other users without needing to be a System Administrator, for example, to troubleshoot user issues. Delegated Administrators are assigned limited admin duties to some of your users, allowing you to focus on other tasks.
- Salesforce Queues: Prioritize, distribute, and assign records for teams who share workloads – like holding areas in your CRM, where records wait for a user to pick them up. Admins can choose which users are added as queue members; any queue members or users higher in a role hierarchy can take ownership of records in a queue. Leads and Cases out of standard objects support queues, but they can also be used for custom objects if needed.
- Account, Opportunity, and Case Teams: A group of users who work on an Account/Opportunity/Case together. Team members and their team roles are displayed in related lists (that are added to the applicable page layouts). There is the option to enable default teams that will add users automatically to accounts that a specific user creates or records that are transferred to them. When it comes to the Account team, for example, access can also be further defined for child records – all in one place.
- Sales Territories (formerly Enterprise Territory Management): This is an advanced feature with many implications on user permissions, which must be reviewed carefully. The mechanism is based on defining territory models, territory types, as well as individual territories. From a record access perspective, you can define both default access levels and per-territory object access for all objects enabled for this functionality.
- Public and Personal Groups: Public Groups can be created by admins and used by the entire organization, but Personal Groups, on the other hand, can be created by individual users on their own. Both groups can contain individual users, users in a given role or territory, or even other groups.
- Manager Groups: These are a different type of group, designed to allow users to share records with their management chain, rather than all managers who share the same role in the hierarchy, especially when it comes to indirect managers.
- Data Category Groups: Similar to folders, Data Category Groups are how Knowledge Articles are organized. The Data Category Visibility option on permission sets, for example, allows you to grant individual access to a certain category only. Starting with the Summer ‘20 release – so quite a few releases ago – standard sharing became available for Lightning Knowledge as well. This means that Data Category Groups no longer control access, but they can still be used for categorization.
How to Share a Record With Experience Cloud Users
- Sharing Sets (Site-Specific Sharing): This is the out-of-the-box mechanism that allows you to extend and tailor community user access based on their related Account or Contact Ids. For example, if you have a custom object related to their Contact, which they should have access to, sharing sets are the way to go.
- Share Groups: These are meant to be used to facilitate record share in digital experiences with millions of users, where high-volume site users own records. These types of users do not have a role, and admins can choose to turn on the Share Group from Setup.
- External Account Hierarchies: “Work like Salesforce role hierarchies. Account records, owned by users with roles in child accounts that are part of an external account hierarchy, share data with the parent accounts in that hierarchy.” (Requires a Partner or Customer Community Plus license.) Read more here.
- Super User Access: “Grant this access to partner users to access more data and records, regardless of sharing rules and organization-wide defaults” (requires a Partner or Customer Community Plus license). Read more here.
Custom Ways to Share Records
This section focuses on custom ways you can use to share records, which entail creating the mechanism yourself, rather than leveraging readily available ways.
- Flow-Based Record Sharing: When it comes to Salesforce declarative automations, there’s no doubt that Salesforce Flow is the Swiss Army knife in an admin’s toolbox. It should come as no surprise that you can use a Flow, for example, to manage record sharing. In the past, code was needed from the get-go to achieve this level of customization. While in a real-world implementation you would consider many more aspects and might even approach this as a Subflow called by another Flow, let’s use a Record-Triggered Flow as an example. In this case, whenever an opportunity is created and it has a user in the Customer Success Manager lookup field, a new Opportunity Share record is inserted for them with Read/Write access to the record.
- Apex-Based Record Sharing: If all of the options you’ve read so far still aren’t enough to fulfill requirements, then code can be used (leveraging a developer’s skillset) to achieve highly complex sharing frameworks.
- Share Record Details Within Screen Flows: Another way to share records information with Salesforce Flow is through a Screen Flow. This option doesn’t share the record directly, but rather creates an in-flow projection of the data which the user can’t access otherwise. This option shouldn’t be used lightly, as it does involve changing the context the Flow runs in. Additionally, this can also be a mechanism to allow users to update certain information on the record.
Alternative Ways to Share Record Data
Thinking ‘beyond the system ways’ to open or restrict access to objects and records, there are several ways users can share record information by drawing attention to the records.
- Chatter: A collaboration tool built into the Salesforce user interface. Its features boost collaboration between users – mirroring that of a social media platform – by posting updates or comments on a record and drawing the attention of other users by tagging, @mentioning, and more.
- Subscribe to a Report: Receive an email containing a report snapshot at a frequency you specify. Other users can create these reports knowing that they are automatically sharing the information with you.
- Dashboard “Viewing As”: Dashboards have a viewing user. The data that’s displayed on the dashboard is determined by that user’s security settings.
- Print a Dashboard: Prefer old-school paper handouts? Here’s another way to share records with others that’s not so obvious.
- Share Records via Slack: Records can be easily shared in private conversations or channels. Once you have decided on the record you’d like to share, the high-level information of the record will be displayed for you to double-check. Then you can proceed with sharing.
Summary
There you have it – over 25 ways to share a record in Salesforce. From permission sets to super user access, Salesforce offers huge versatility; it caters for every possible sharing use case to give you greater control over the visibility and accessibility of your org.
How many of these methods have you used previously, and which are new to you? Let us know in the comments below.
Comments: