> 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/pods-and-hierarchies.md).

# Pods and Hierarchies

Group users, assign record access, and configure how that access flows through your organization.

A Pod is a group of users that can receive access to records. Use Pods to organize access around a team, territory, or reporting group. A hierarchy connects Pods so that record access can roll up to groups above them.

For example, a territory Pod can give its members access to a set of accounts. A user-based hierarchy can give a manager access to records available to the reps below them.

### Before you begin

Confirm that you can manage Governance settings and that the users you want to add are active in your workspace.

Decide which users belong together and which records they need. If you are building a reporting hierarchy, have the reporting structure ready. Review the OWDs first: a public record baseline may already give users access beyond the Pods you create.

### Pod membership and record access

Two settings on a membership have different purposes:

| Setting      | Meaning                                                                                                                                                                                  |
| ------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Role         | The user’s relationship to the Pod. Member is standard membership; Owner identifies responsibility for managing the Pod. The reporting hierarchy guide requires Pod owners to be admins. |
| Access level | The maximum record access available through that membership: Read, Edit, or Full                                                                                                         |

Read allows viewing. Edit allows changes where resource and field permissions also permit them. Full provides the highest record-access level; the additional operations it permits depend on the resource.

A membership access level limits that access path. A user may still receive broader access through ownership, another Pod, sharing, or an organization-wide grant. Use Access Provenance to see the combined result.

### Create a Pod and add members

1. Open **Settings → Access → Governance** and select **Pods**.
2. Select **Create POD**. Enter a name and description that explain the group’s purpose, and choose the appropriate label. For reporting groups used in reporting hierarchy, choose **Role**.
3. Open the Pod and select **Members → Add Member**.
4. Select the users and configure their membership Role and Access level.
5. Select **Add Member**.

Use names that distinguish the group’s purpose, such as “West Sales Reps” or “West Sales Managers.” Group users who need the same access rather than creating a Pod for every person.

### Give a Pod access to records

Open the Pod and select **Assign Records**. Choose the records the group needs, then set the appropriate access level for the assignments. Review the records in the Pod’s resource tabs, such as Accounts or Deals.

Assigning a record to a Pod makes it available through that Pod’s access path. The result also depends on membership access levels and the required resource and field permissions.

For example, giving the West Sales Pod Edit access to an Account does not make every field editable. Each user still needs Update permission for Accounts and permission to edit the particular field.

This is a Governance record-access assignment. It is distinct from configuring the CRM or warehouse Account Assignment rules that determine a user’s assigned accounts.

### Connect reporting groups

Use a user-based hierarchy when managers should receive record access through their reports.

1. In **Pods**, open **Hierarchy** and select **User-based**.
2. Connect the manager’s Role Pod as the parent of the direct reports’ Role Pod.
3. Repeat for the other reporting groups.
4. In Live mode, connections save immediately. In Draft mode, select **Save** to apply your changes.

For a complete reporting-structure walkthrough, see **Reporting Hierarchy**.

#### What rolls up

Record access can roll from a lower Pod to Pods above it. Reports do not receive a manager’s records simply because their Pod is below the manager’s Pod.

Resource permissions, field permissions, and Permission Sets do not roll up with record access. A manager who can see a report’s Account must still have the required field access to see its protected information.

Rollup behavior also depends on the resource. The supplied product documentation identifies workflow configurations and Chat Skills as resources where record-access rollup is disabled. Do not assume that every resource follows the Account hierarchy behavior.

#### Hierarchies and cascades

A Pod hierarchy determines who else can receive record access. A parent-child cascade determines which linked records can become accessible with a parent record.

For example, a manager might receive access to a rep’s Account through the hierarchy. An enabled Account → Deal cascade can then provide access to linked Deals. Field permissions remain separate in both cases.

### Verify the result

Use [**Access Provenance**](https://docs.rox.com/development/product/governance/access-provenance) to inspect a representative user and record. Confirm which Pod or hierarchy grants access and the resulting access level. Check a sensitive field separately if the user should have limited visibility or editing rights.

Also inspect someone outside the intended group. This can reveal a broad OWD or another grant that makes the records available more widely than expected.

### Maintain access when teams change

When a user changes teams, review their old and new memberships and any direct sharing. When reporting lines change, update the hierarchy connections. When a territory changes, review the records assigned to its Pods.

Removing a membership or hierarchy connection removes that route to access. It does not necessarily remove access granted elsewhere. Rerun Access Provenance to confirm the final result.