> ## Documentation Index
> Fetch the complete documentation index at: https://docs.camo.ag/llms.txt
> Use this file to discover all available pages before exploring further.

# Role-Based Access Control (RBAC)

> Learn how to configure and manage role-based access control to ensure users only see and do what they're supposed to.

## Overview

Role-Based Access Control (RBAC) is a security model that restricts platform access based on assigned roles and permissions. Instead of configuring access user by user, you define roles with specific permissions, assign those roles to groups of users, and let the system handle the rest.

RBAC in this platform is built around two special concepts you'll use on every account: the **Admin Role** and the **Default Role**.

## Core Concepts

### The Admin Role

Every organization has a single, automatically created **Admin Role**. Users in this role have one permission: **Manage Users** — the ability to manage user roles, user groups, and permissions.

This role cannot be edited or deleted. Users who previously held the "Organization Manager" permission were automatically migrated into this role.

### The Default Role

The **Default Role** is the baseline applied to **every single user** in the organization, regardless of any other role assignments. Whatever permissions are toggled on in the default role, every user gets them.

Additional roles assigned to a user are **additive** on top of the default role — they never subtract from it.

<Info>
  For most organizations, setup is simply: configure the default role with the right baseline permissions. Only then layer on additional roles for groups that need more.
</Info>

### Groups

A **Group** is a collection of users. Roles are assigned to groups, not directly to individual users. To give a set of users a specific permission, you:

1. Create a group and add the users to it
2. Create a role with the appropriate permissions
3. Assign that role to the group

A user can belong to as many groups (and therefore roles) as needed. Their effective permissions are the union of the default role plus all group-assigned roles.

### Roles

Roles define a set of permissions. **Name roles based on what access they grant, not the job title of who holds them.** A role like "Farm Sales Access" or "AI Tool Access" is reusable across different user groups. A role named after a specific team is harder to reuse and harder to audit.

Good role names: `Farm Sales Access`, `User Engagement Reports`, `AI Tool Access`, `Crop Insurance Policies`

Avoid: `Marketing Team`, `Andrew's Group`, `Sales`

## Initial Setup

For most enterprise organizations, initial setup follows this pattern:

<Steps>
  <Step title="Configure the Default Role">
    Go to **Settings → Users & Roles → Roles** and open the Default Role. Toggle on permissions for all features the organization currently has access to.

    **When in doubt, over-provision.** Enable everything the org is used to seeing and let them dial back anything they don't want. It's much easier than troubleshooting why something is missing after go-live.
  </Step>

  <Step title="Create Groups for Specialized Access">
    If certain users need permissions beyond the default (e.g. a leadership group that should see engagement reporting, or a team with crop insurance access), create a group for them under **Settings → Users & Roles → Groups**.
  </Step>

  <Step title="Create Roles for Those Groups">
    Create a role with the relevant permissions and assign it to the group. The users in that group will now have the default permissions plus the additional ones.
  </Step>

  <Step title="Verify User Permissions">
    Use the user permission lookup tool to confirm a specific user's effective permissions reflect what you configured. Search for a user by name to see exactly what they have access to.
  </Step>
</Steps>

## Creating a Group

<Steps>
  <Step title="Open Group Management">
    Navigate to **Settings → Users & Roles → Groups** and click **New Group**.
  </Step>

  <Step title="Name the Group">
    Give the group a descriptive name (e.g. "Crop Insurance Team", "Sales Leaders").
  </Step>

  <Step title="Add Members">
    Add the relevant users to the group. You can assign a role during creation if one already exists, or skip this and assign it later.
  </Step>

  <Step title="Save">
    Click **Save**. The group now appears in your roles list and can have roles assigned to it.
  </Step>
</Steps>

## Creating a Role

<Steps>
  <Step title="Open Role Management">
    Go to **Account Settings → Users Management → Roles** and click **Create Role**.
  </Step>

  <Step title="Name the Role">
    Use a permission-describing name, not a person or team name. Good: "Engagement Reports Access". Bad: "Marketing".
  </Step>

  <Step title="Configure Permissions">
    Toggle on the permissions this role should grant. Permissions are grouped by feature area — expand each section to review.
  </Step>

  <Step title="Assign to a Group">
    After saving, open the role and assign it to one or more groups. The role does nothing until it is assigned.
  </Step>
</Steps>

## How New Feature Permissions Work

When a new feature is released that introduces a new permission, that permission **will not be automatically added to existing roles**. Admins will need to go in and explicitly enable it on any role they want it applied to.

<Tip>
  Features that don't warrant their own permission (e.g. a small UI widget on an existing page) will just roll out to everyone without a new permission toggle.
</Tip>

## Best Practices

**Principle of least privilege.** Start with the features all users should have access to

**Name roles by what they grant, not who holds them.** Roles should be reusable across groups. "AI Tool Access" could apply to a sales team and a leadership group and is easy to identify what permissions belong to that role.

**Create groups for exceptions, not the rule.** Most users should be covered by the default role alone. Groups and additional roles are for users who need something beyond the baseline.

## Frequently Asked Questions

<AccordionGroup>
  <Accordion title="Can a user have more than one role?">
    Yes. A user receives the default role automatically, and they receive additional roles through any groups they belong to. Their effective permissions are the combined set of all of those roles. There is no limit to how many groups a user can be in.
  </Accordion>

  <Accordion title="What is the difference between the Admin Role and the Default Role?">
    The **Admin Role** has exactly one permission: Manage Users. It controls who can configure RBAC settings. The **Default Role** is a baseline applied to every user in the organization and defines what everyone can do. These are separate and serve different purposes.
  </Accordion>

  <Accordion title="Do I have to assign the Default Role to users?">
    No. The Default Role is applied automatically to all users. You only need to configure its permissions.
  </Accordion>

  <Accordion title="What happens when a new permission is introduced for a new feature?">
    New permissions are not automatically added to existing roles. An admin must go in and enable the new permission on any role they want it applied to.
  </Accordion>

  <Accordion title="Can I check what permissions a specific user has?">
    Yes. Use the user permission lookup in User Management to see the full list of effective permissions for any user. This accounts for the default role and all group-assigned roles combined.
  </Accordion>

  <Accordion title="What happens if a permission is missing for a user?">
    They simply won't see or be able to access that feature. Nothing breaks — it's just hidden or unavailable. Identify the missing permission, add it to the appropriate role, and they'll regain access immediately.
  </Accordion>
</AccordionGroup>

##