> For the complete documentation index, see [llms.txt](https://docs.rox.com/development/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.rox.com/development/product/governance/permission-sets.md).

# 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](https://docs.rox.com/development/product/governance/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**](https://docs.rox.com/development/product/governance). 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.