Permission Sets

Bundle resource and field permissions, grant access to selected users, and control how sensitive fields are displayed.

Permission Sets collect permissions that you can assign together. Use them when selected users need access beyond the organization-wide baseline, such as permission to edit particular fields or manage columns for a resource.

A Permission Set does not automatically provide access to every record. Resource, record, and field permissions must still work together.

What a Permission Set contains

Permission type	What it controls	Example
Resource permissions	Actions on a type of data	Update permission for Deals
Field permissions	Reading or editing specific fields, including supported masking options	Read Amount, or allow selected users to edit it
Custom resource permissions	Additional operations supported for that resource	Manage Columns

The available controls depend on the resource. A custom permission is a supported product operation; its presence in this guide does not mean admins can define arbitrary new operations.

Broad permissions such as View All and Modify All deserve particular attention because they can expand access beyond selected records or teams. Use Access Provenance to inspect their effect.

Before you begin

Confirm that you can manage Governance settings. Decide who needs the permissions and what they should be able to do.

Review the resource, record, and field baselines under General. Permission Sets add access. Leaving a permission unselected does not remove the same permission granted by the baseline or another Permission Set.

Create a Permission Set

1. Open Settings → Access → Governance and select Permission Sets.

2. Select New permission set and give it a clear name and description.

3. Under Resources, select the actions the intended users need for each resource type.

4. Under Custom resource permissions, select any additional supported operations they need.

5. Under Fields, select the resource and configure the relevant fields’ Read, Edit, and masking options.

6. Save the Permission Set.

Describe the intended access in the name, such as “Deal Amount Editors.” A purpose-based name makes it easier to review the set later than a name tied to one employee.

Assign the permissions

Assign directly to a user

Open the Permission Set’s Assignments tab and select Add users. Select the users who need it and complete the assignment.

A direct assignment makes those permissions available to the user independently of a particular Pod membership. Required record access still applies unless a permission explicitly grants broader record access.

Apply field rules through a Pod membership

The documented current model also allows a Permission Set on a user’s Pod membership. Use the Permission Set option in the Pod’s member settings when that membership needs additional field-level access for records assigned to the Pod.

This is different from assigning the set directly to the user. Do not assume the membership assignment grants its resource-level permissions organization-wide, or that its field permissions roll up to managers.

See Pods and Hierarchies for the relationship between membership and record access.

Protect fields using the baseline and grants

Choose the field baseline according to what everyone with the required record access should be able to do.

Requirement	Configuration approach
Everyone can read fields, but only selected users can edit specified fields	Use a Read-only field baseline, then grant Edit for the selected fields through Permission Sets
Selected fields must be hidden from users who lack an explicit grant	Use a Hidden field baseline for that resource, then grant the required fields through Permission Sets
Selected users should see only a masked representation	Start from Hidden, then configure the supported masking option in the relevant Permission Set

The baseline applies at the resource level. Setting it to Hidden affects fields throughout that resource, so account for all fields users need to read, not just the sensitive one.

Masking options include representations such as a hash or the last four characters, where supported. Check for other grants that provide full visibility: a masked grant should not be treated as overriding broader access from another source.

Example: only selected users can edit Deal Amount

Suppose everyone with access to a Deal should be able to read its fields, while only selected users should edit Amount.

Set the Deal field baseline to Read-only. Create a Permission Set that grants Edit to Amount and assign it to those users. Each user still needs Update permission for Deals and Edit access to the individual Deal.

Before concluding that other users cannot edit Amount, check whether another Permission Set or broader grant already permits it.

Verify and change permissions

Use Access Provenance → Field Access to see who can read or edit a field and which grants provide that access. Use User Access when investigating a specific person.

Where available, use Simulate removal before changing a field Permission Set. After the change, rerun Access Provenance to verify the result.

Removing a Permission Set assignment removes the permissions supplied through that assignment. A user may retain access through another set, the organization-wide baseline, or another applicable path. Inspect all paths when reducing access.