Policy Resolution
Prompt flows are workspace-capability driven and then filtered by plan and feature gates.
Effective Permission = Workspace Role Capability AND Plan/Feature GateOperation To Gate Mapping
| Operation | Gate |
|---|---|
| Add prompt version | canContribute |
| Edit version/default/metadata | canUpdate |
| API integration actions | canUpdate |
| Delete prompt/version | canDelete |
| Move private prompt to workspace | canUpdate |
Role Availability Matrix
| Role | View | Add Version | Edit/Default/API | Delete | Move Private Prompt |
|---|---|---|---|---|---|
| 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:
Prompt UI controls can vary by flow; backend authorization remains authoritative.
FAQ
How are prompt permissions evaluated?+
In current implementation, prompt permissions are primarily workspace-capability driven, then constrained by plan and feature gates.
Q1
Can Contributor edit prompts?+
Yes. Contributor can add and edit versions, but cannot delete prompt versions or prompts.
Q2
Can Reader perform API integration actions?+
No. Reader has view-only prompt access and cannot run edit/default/API-management actions.
Q3
Can Guest access workspace prompts?+
No. Guest does not have workspace-owned prompt management access.
Q4
Are prompt run controls always mapped to canRun?+
Prompt run behavior is often constrained by page access and backend authorization rather than explicit canRun UI checks.
Q5
Tip:
For cross-entity policy details, see Workspace Permissions Matrix.