Policy Resolution
Runtime access is resolved through role capability, chatbot-level capability, and plan gates.
Effective Permission = Workspace Role Capability AND Entity Capability AND Plan/Feature GateOperation To Gate Mapping
| Operation | Gate |
|---|---|
| Open design or leads page | canRead |
| Preview or run chatbot | canRun |
| Edit content and settings | canUpdate |
| Publish or revert | canUpdate |
| Delete chatbot | canDelete |
| Move across workspace or org | canTransfer |
Role Availability Matrix
| Role | View | Run | Edit/Publish | Delete | Transfer |
|---|---|---|---|---|---|
| Owner | Yes | Yes | Yes | Yes | Yes |
| Admin | Yes | Yes | Yes | Yes | No |
| Contributor | Yes | Yes | Yes | No | No |
| Reader | Yes | Yes | No | No | No |
| Guest | No | Limited | No | No | No |
Note:
UI controls can occasionally appear in edge states, but backend authorization is always enforced.
FAQ
How are chatbot permissions calculated?+
Effective permission is based on workspace role capability, chatbot capability flags, and plan or feature gates.
Q1
Can Admin transfer chatbots by default?+
No. Admin can manage most chatbot operations, but transfer is role-capped and blocked unless explicitly granted.
Q2
What can Reader do?+
Reader can view and run chatbots where supported, but cannot edit, publish, delete, or transfer.
Q3
Why can Guest run some flows but not open details?+
Guest is intentionally restricted to limited run entry points and does not get chatbot management page access.
Q4
Can plan features still block actions?+
Yes. Role access does not bypass feature gates. If a feature is disabled in plan settings, the action stays unavailable.
Q5
Tip:
For cross-entity policy details, see Workspace Permissions Matrix.