You are here:
How Actionable List Sharing Works
Sharing works differently for an actionable list and for its members. A list uses standard sharing, but a member doesn't. Understanding both models helps you troubleshoot unexpected access and plan sharing before you roll out a list to your team.
This sharing model applies to actionable lists however they're created, including through Actionable Segmentation, List Builder for Data 360, and Data 360 data model objects.
Sharing involves two related objects that behave differently:
- The actionable list uses standard Salesforce sharing. You share a list with other users to grant them access.
- The actionable list member doesn't use standard sharing. Read access follows the reference record that the member is based on, and edit and delete access follow the parent list.
Who Can Access an Actionable List?
An actionable list is a standard Salesforce object governed by your org's sharing model.
- Org-wide default: The actionable list's org-wide default is Private. This default is locked and can't be changed in Sharing Settings.
- Owner access: The list owner, typically the admin who created the list, has full control of the list.
- Shared access: An owner shares a list with other users one by one by using the Share button on the list record, and grants either Read Only or Read/Write access. Other users gain access through these shares along with the object permissions on their profile.
- View who has access: To see everyone with access to a list, use the Sharing Hierarchy button on the list record.
Access to a list drives edit access to its members. A user with Read/Write access on a list can edit every member in that list. Member read access is separate and follows the reference record, as described in the next section. To share a list, see Share Actionable Lists.
Who Can Access a List Member?
The Actionable List Member object's org-wide default is Public Read Only for internal users and Private for external users. This default is locked and can't be changed in Sharing Settings.
Unlike a standard object, an actionable list member doesn't use standard platform sharing. Sharing rules, manual sharing, and criteria-based sharing don't apply to member records. Instead, read access is delegated from the reference record, such as an Account or Contact, and edit and delete access follow the parent list. The table shows how each access level is granted.
| Access Level | How It's Granted |
|---|---|
| Read | Delegated from the reference record, such as an Account or Contact. A user who can view the reference record can view the corresponding member. |
| Edit | Granted when the user owns the member record, owns the parent actionable list, or has Read/Write access on the parent actionable list. |
| Delete | Granted by the same criteria as Edit. There's no separate access level required to delete a member. |
How Member Edit and Delete Access Is Determined
When a user tries to edit or delete an actionable list member, the system evaluates access in this order and stops at the first rule that applies:
- Administrator access: Users with administrative privileges have full access to all actionable list members.
- Profile permissions: The user's profile needs the required object permission on the Actionable List Member object. Without it, access is denied regardless of any sharing grant.
- Record lock: If the member record is locked, for example, by an approval process, access is denied.
- Record ownership: If the user owns the member record, access is granted.
- Parent list access: If the user isn't the member owner, the system checks the parent actionable list. A user who owns the parent list or has Read/Write access on it can edit and delete every member in that list.
Key Behaviors
You can't share an individual member record. To grant edit access, share the parent actionable list instead. New members added to a list follow the same model automatically, with no extra configuration.
Examples
- The user has Read/Write access on the list. A user with Read/Write access on the Q3 Campaign Targets list can edit every member in that list.
- The user owns some members but has only Read Only access to the list. A user who owns one member of a list, but has only Read Only access to the list, can edit only the member they own. They can't edit the remaining members, because edit access needs Read/Write access on the list.
- The user's profile lacks the permission. A user with Read/Write access on the list but whose profile doesn't permit editing actionable list members can't edit any members.
