Prompts API Permission Matrix
Workspace-role rules for prompt versioning, editing, defaulting, API integration, deletion, and move-to-workspace actions.
Workspace Role Capability AND Plan/Feature GateOperation To Gate Mapping
| Operation | Gate |
|---|---|
| Add new 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 |
Frequently Asked Questions
Everything you need to know
How are prompt permissions evaluated?
Prompt flows are primarily workspace-capability driven in current implementation, then filtered by plan/feature gates.
Can Contributor edit prompts?
Yes. Contributor can add and edit prompt versions, but cannot delete prompt versions or prompts.
Can Reader call prompt APIs?
Reader has view-only access in workspace prompt management and cannot perform edit/default/API-management actions.
Can Guest access workspace prompt pages?
No. Guest does not have workspace-owned prompt management access.
Are run controls explicitly tied to canRun?
In current prompt UI, run behavior is mostly constrained by page access and backend authorization rather than explicit canRun gating.
Still have questions?
Contact our support teamNeed cross-entity guidance across all workspace resources?