> 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/admin-guide/governance.md).

# Governance

Control access to records and fields, organize access through teams, and understand why a user can see or change information in Rox.

Governance determines what users can access and change in Rox. Use it to establish organization-wide defaults, give teams access to the records they work on, and protect fields that need more specific controls.

For example, you might let sales reps edit their own accounts, give managers visibility into their teams’ accounts, and allow only selected users to edit a revenue field. Each requirement uses a different part of the access model.

### How access works

Rox evaluates access at three levels:

| Level        | What it controls                                     | Example                                                    |
| ------------ | ---------------------------------------------------- | ---------------------------------------------------------- |
| **Resource** | Actions on a type of data, such as Accounts or Deals | Whether a user can update Deals                            |
| **Record**   | Access to an individual item                         | Whether a user can edit a particular Deal                  |
| **Field**    | Access to information within an accessible record    | Whether a user can read or edit the Amount field on a Deal |

The required permissions must work together. To edit the Amount field on a Deal, a user needs Update permission for Deals, Edit access to that Deal, and Editable access to its Amount field. Permission at one level does not automatically provide permission at the others.

A user may receive access through more than one route. Within a layer, grants can combine to provide broader access. A restrictive setting on one route does not cancel a more permissive grant from another route. The resulting access must still satisfy the other required layers.

### The parts of Governance

| Control                           | Use it to                                                                        |
| --------------------------------- | -------------------------------------------------------------------------------- |
| Organization-wide Defaults (OWDs) | Establish the baseline for resource, record, and field access                    |
| Pods                              | Group users and give them access to records                                      |
| Hierarchies                       | Let record access roll up through a configured hierarchy                         |
| Permission Sets                   | Bundle resource permissions, field permissions, and supported custom permissions |
| Ownership and sharing             | Provide access to particular records                                             |
| Parent-child access cascades      | Extend record access to linked records, such as an Account’s Deals               |
| Access Provenance                 | Inspect the paths that give a user access and verify changes                     |

#### Start with the organization’s baseline

OWDs establish the starting point for access. Additional grants can broaden it.

If your record baseline makes every Account readable, removing a user from an Account’s Pod will not make that Account private to them. Likewise, a field baseline that makes fields Editable cannot be narrowed for one user simply by assigning a Permission Set with fewer permissions.

Choose the baseline for the access everyone should have, then grant additional access where needed.

#### Use Pods and Permission Sets together

Pods answer which records a group of users can reach. Permission Sets provide resource and field permissions, along with supported custom permissions.

These controls serve different purposes. A manager may receive record access through a Pod hierarchy and still be unable to edit a field because the required field permission is missing. Resource and field permissions do not roll up the Pod hierarchy with record access.

#### Understand access to related records

A cascade can extend access from a parent record to linked child records. For example, an enabled Account → Deal rule can give users access to Deals linked to an Account they can access.

With **Inherit**, the child receives the parent’s access level through that path. A fixed Read, Edit, or Full level caps the access granted through that path at the lower of the configured level and the user’s parent-record access.

A cascade does not grant field permissions. Other access paths can also grant access to the child, so lowering a cascade cap does not necessarily lower the user’s overall access to that child.

### Where to start

| Your goal                                                             | Guide                                                                                                                    |
| --------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ |
| Set the organization’s baseline or configure access to linked records | [Organization-wide Defaults (OWDs)](https://docs.rox.com/development/product/governance/organization-wide-defaults-owds) |
| Give a team or territory access to records                            | [Pods and Hierarchies](https://docs.rox.com/development/product/governance/pods-and-hierarchies)                         |
| Configure resource permissions, field access, or masking              | [Permission Sets](https://docs.rox.com/development/product/governance/permission-sets)                                   |
| Set up visibility through a reporting structure                       | [Reporting Hierarchy](https://docs.rox.com/development/product/governance/ceo-mode)                                      |
| Explain unexpected access or verify a change                          | [Access Provenance](https://docs.rox.com/development/product/governance/access-provenance)                               |

Before changing settings, confirm that you can manage Governance in your workspace. Start with a representative user and record, then use Access Provenance to check the result.

### Scope and boundaries

Governance controls should be understood in the context of the resource and feature you are configuring. Read, Edit, and Full describe record access. The operations available at each level can differ by resource. Full access to a record is not the same as being an organization administrator.

[Account Assignment](https://docs.rox.com/development/product/organization-level-configurations/account-assignment) determines which accounts are assigned to a user. Governance determines access. Changing an assignment alone does not establish that a user has lost every path to an account.

Reporting Hierarchy uses the configured Pod hierarchy to provide visibility. A job title alone does not establish the hierarchy or grant access. See the [Reporting Hierarchy guide](https://docs.rox.com/development/product/governance/ceo-mode) for setup and the scope of that experience.

For Chat, agents, and other product features, use the relevant feature guide alongside these access controls. Record visibility alone does not establish permission to perform every action available in a feature.