Policy Resolution
Persona permissions follow workspace role capability with plan and feature-gate enforcement.
Effective Permission = Workspace Role Capability AND Plan/Feature GateOperation To Gate Mapping
| Operation | Gate |
|---|---|
| Add persona version | canContribute |
| Edit version or default | canUpdate |
| API integration actions | canUpdate |
| Delete persona or 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 |
Note:
Backend authorization is always final for persona updates, deletions, and defaults.
FAQ
How are persona permissions evaluated?+
Persona permissions are primarily workspace-capability driven in current implementation, then constrained by plan and feature gates.
Q1
Can Contributor edit persona versions?+
Yes. Contributor can add and edit versions, but cannot delete persona versions or personas.
Q2
Can Reader edit personas?+
No. Reader can view but cannot add, edit, default, or delete persona versions.
Q3
Can Guest access workspace personas?+
No. Guest does not have workspace-owned persona management access.
Q4
Why are some controls visible but action is blocked?+
In edge UI states, controls may render; backend authorization still enforces role and capability limits.
Q5
Tip:
For cross-entity policy details, see Workspace Permissions Matrix.