Access management
Who can view and edit a prompt: every teammate can view, the creator owns it, and the owner invites other team members as editors. How to grant and revoke edit access.
Access to a prompt has two levels, layered on top of your team. Everyone on the team can view every prompt; editing is limited to the prompt's owner and the editors they invite.
The model
| Role | Who | Can do |
|---|---|---|
| Team member | Anyone on the team. | View any prompt, its full version history, and diffs. Fetch it from the SDK. |
| Editor | A team member the owner has invited. | Everything a member can, plus save new versions, move/remove deploy labels, and edit the description. |
| Owner | The person who created the prompt. | Everything an editor can, plus invite and revoke editors, and delete the prompt. |
- The creator is the owner. When you create a prompt, you become its owner automatically — nothing to set up.
- Viewing is always open to the team. Access management never hides a prompt from teammates; it only controls who can change it. This keeps prompts discoverable while protecting what's live.
- You can only invite team members. Edit access is granted to people who already belong to the team — invite someone to the team first (Settings → Members) if they aren't there yet.
Grant edit access
- Open the prompt and click Members in the top bar.
- In the panel, the owner is shown with a crown; current editors are listed below.
- As the owner, pick a teammate from Invite a teammate… — they immediately gain edit access.
Only the owner sees the invite control. Editors and other members see the list read-only, so everyone can tell who can change the prompt.
Revoke edit access
In the same Members panel, the owner removes an editor with the trash icon next to their name. Access is revoked immediately — on their next action they fall back to view-only.
What view-only looks like
A teammate without edit access can open the prompt, read every version, copy hashes, and diff versions — but the editing surfaces (messages, config, description) are disabled and Save version is greyed out with a note to ask the owner for access. The rules are enforced on the server too: a write from a non-editor is rejected with 403, so the UI state and the API agree.
Authorship in the timeline
Every saved version records who made the change (by email) and their commit message. The activity timeline resolves that to the teammate's name, so history shows exactly who shipped what — independent of who currently holds edit access.
Does this affect the SDK?
No. The SDK read path fetches a prompt by your site id and name; it is unaffected by editor access, which is a dashboard authoring concern. Any teammate — and your running application — can always fetch and compile a prompt. See SDK reference.
Where to go next
Version control
Content-addressed, immutable versions identified by hash, full history you can diff any-to-any, movable deploy labels, instant rollback, and the precedence the SDK follows to resolve which version your app gets.
Variables & templating
Declared variables with optional defaults, message-list placeholders, and the strict Mustache-subset syntax that fills them. Compile always succeeds with whatever you pass; a missing value falls back to the default, or empty.