Per-chatbot permissions

By default, organization-wide roles (Owner, Admin, Member) decide what each teammate can do across all chatbots. Per-chatbot permissions let you override that for a single bot — useful for client-specific bots, internal-only bots, or bots that need a stricter editor list.

In this guide:

• When to use per-chatbot permissions
• The actions you can grant or restrict
• How precedence works
• Examples

When to use per-chatbot permissions

• Agency or consulting work: you manage a client’s bot but only want the client to see their own bot, not the rest of your portfolio.
• Internal-only bots: an HR-policy bot should be readable by employees but only editable by HR.
• Read-only deployments: support managers can view conversations and analytics but not change the system prompt.

For everything else, organization-wide roles are simpler.

Step 1: Open the Permissions tab

On the chatbot detail page, click Permissions in the left rail.

Screenshot: The Permissions tab with a per-member matrix of allowed actions.

You’ll see a table: every member of the organization on the left, every chatbot action on the top.

Step 2: Pick the actions to grant

The actions you can grant or restrict per chatbot:

Step 3: Edit the matrix

Toggle the cells for each member. Save when done.

Step 4: Understand precedence

Permissions stack:

1. Org role grants the maximum. A Member can never get delete on a chatbot, even if you toggle it on the matrix.
2. Per-chatbot permissions narrow. You can take away update from an Admin on a specific chatbot, but you can’t grant delete to a non-Owner.
3. The chatbot owner always retains all permissions. That’s the user who created it (transferable from this same page).

This matches the spirit of the Roles & permissions framework — per-chatbot permissions are a tightening, not a loosening.

Examples

Client-only access

A consulting agency runs AcmeBot for the Acme Inc account. Acme’s Marketing Director, Carla, gets:

• read on AcmeBot ✅
• test on AcmeBot ✅
• Everything else on AcmeBot ❌
• No access at all to OtherClientBot.

The agency’s lead consultant is an Org Admin and retains full access to all bots.

Read-only support manager

A support manager, Devon, is a Member of the org. On the customer-facing SupportBot, Devon gets read so they can view conversations and analytics but not change Guidelines. On internal HRBot, Devon has no access at all.

Common pitfalls

• Granting update without read. Counter-intuitive but possible — they can’t see what they’re editing. The UI warns; correct it.
• Removing your own permissions. If you remove update for yourself on a bot, you lose access to this Permissions tab too. An Org Owner can always restore.

What’s next