Personas API Permissions
Personas API Permission Matrix
Role-by-role access for workspace-owned personas, including version management, edit/default actions, deletion, and move operations.
Effective permission formula:
Workspace Role Capability AND Plan/Feature GateOperation To Gate Mapping
| Operation | Gate |
|---|---|
| Add persona version | canContribute |
| Edit/default/API actions | canUpdate |
| Delete persona/version | canDelete |
| Move private persona to workspace | canUpdate |
Role Availability Matrix
| Role | View | Add Version | Edit/Default/API | Delete | Move Private Persona |
|---|---|---|---|---|---|
| Owner | Yes | Yes | Yes | Yes | Yes |
| Admin | Yes | Yes | Yes | Yes | Yes |
| Contributor | Yes | Yes | Yes | No | Yes |
| Reader | Yes | No | No | No | No |
| Guest | No | No | No | No | No |
Frequently Asked Questions
Everything you need to know
How are persona permissions evaluated?
Persona permissions are primarily workspace-capability driven in current implementation, then constrained by plan/feature gates.
Can Contributor edit persona versions?
Yes. Contributor can add and edit versions, but cannot delete persona versions or personas.
Can Reader run persona conversations?
Reader can view persona pages but cannot add/edit/delete persona configurations.
Can Guest manage workspace personas?
No. Guest does not have workspace persona management access.
What if some controls are visible but blocked?
Backend authorization is authoritative. UI rendering edge states do not override access checks.
Still have questions?
Contact our support teamNeed cross-entity guidance across all workspace resources?