Introducing the Ochre AI support workspace. Start a 14-day trial

Roles & permissions in Ochre

Default roles, custom roles, and how to control who can do what across your workspace.

Updated 3 min read

Roles & permissions in Ochre

Every Ochre workspace ships with four default roles that cover most teams out of the box. When those don’t fit, you can build custom roles with the exact permission set you want and assign them to teammates from the members table.

The 4 default roles

| Role | What they can do | |---|---| | Owner | Full control, including dangerous operations like deleting the workspace. Every workspace has at least one owner. | | Admin | Everything an owner can, except destructive workspace-level operations (Danger Zone). | | Agent | The day-to-day support persona. Reply to conversations, manage customers, read knowledge & reports. Cannot change workspace settings, integrations, billing, or team membership. | | Light Agent | Read-only access to the inbox, customers, and knowledge base. Cannot reply or change anything. |

What permissions cover

Permissions are grouped into 13 areas. Each area has a Read level and a Write level — except action-only areas like Danger zone, which only have Write.

  • Inbox (inbox.read, inbox.write) — view, reply, assign, and close conversations.
  • Customers (customers.read, customers.write) — browse the customer directory and edit profiles.
  • Knowledge base (knowledge.read, knowledge.write) — read and author help-center articles.
  • AI agent (ai.read, ai.write) — configure AI behavior, brain, and autopilot.
  • Reports (reports.read, reports.write) — view analytics, NPS, CSAT, and AI savings.
  • Integrations (integrations.read, integrations.write) — connect and configure Slack, Linear, GitHub, Stripe, and the rest.
  • Billing (billing.read, billing.write) — plans, invoices, payment methods.
  • Team & roles (team.read, team.write) — invite teammates, assign roles, define permissions.
  • Workspace (workspace.read, workspace.write) — branding, domains, workspace identity.
  • Live chat widget (widget.read, widget.write) — the customer-facing chat widget configuration.
  • Routing (routing.read, routing.write) — conversation assignment rules.
  • Surveys (surveys.read, surveys.write) — CSAT and NPS settings.
  • Danger zone (danger.write) — workspace deletion and similar destructive ops.

Read vs Write

Each permission area can be set to one of three levels:

  • None — the area is hidden from the user entirely. The sidebar item disappears, and navigating directly redirects them away.
  • Read — they can see the area, but every form and action is disabled.
  • Write — full access to view and change.

Custom roles

When the four defaults don’t map to how your team actually works, build a custom role.

Go to Workspace settings → Team → Roles & permissions → Create custom role. Name it (for example, “Billing only”), pick a level for each permission area, and save. Once created, the role shows up alongside the defaults in the members table — assign it to teammates the same way you’d assign Agent or Admin.

A few common shapes:

  • A finance ops person who only needs Billing read/write — everything else set to None.
  • A QA reviewer with Read on every area and Write on nothing, so they can audit without touching anything.
  • A product manager with Write on AI agent and Knowledge base, Read everywhere else.

Things to know

  • Owners always retain full access. You can’t lock yourself out by editing the Owner role.
  • A custom role can only be deleted when it has zero members. Reassign anyone on the role first, then delete.
  • Default roles can be viewed but not edited. If you want to tweak a default, copy it into a custom role and adjust there.
  • Permission changes take effect on the next page load. Active sessions don’t need to sign back in.
  • The built-in Owner role is the only one that can grant the Owner role to someone else.

How permission checks work under the hood

For curious admins: every server action and page guard reads the caller’s role and checks the requested permission key. If the role doesn’t grant the level needed, the request is denied and returns forbidden_<key> (for example, forbidden_billing.write). The check is cached per-request, so a complex page that asks ten times only pays the cost once.

Was this article helpful?

Roles & permissions in Ochre — Ochre · Ochre