Tutorial: Review and Publish a Version

In the previous tutorial you saved a version directly. That works for solo experiments but isn't how teams ship to production. This tutorial walks through the review workflow: comments, approvers, and the publish gate.

Time: ~10 minutes
Prereqs: First prompt tutorial completed.

The model

Every project has members with roles. One of those roles is Approver.

• Anyone in the project can edit the prompt and save versions (drafts).
• Only an Approver can promote a version to active or release it to environments.
• Anyone can comment on a version — leaving notes, suggesting changes, requesting fixes.

This gives you a lightweight PR-style review without a separate code-review system.

1. Add a teammate to the project

If you're working solo, skip to step 2 and pretend.

Open project settings

From the project page, click Settings → Members.

Invite

Enter the teammate's email. Choose role Member (regular contributor) or Approver (can publish). Click Invite.

They accept

They get an email or in-app notification. Once accepted, they appear in the members list.

TIP

A user must already be in the organization before they can be added to a project. If they're not, invite them to the org first (Organization Settings → Members).

2. Draft a new version

Edit the welcome_email prompt. Change something — say, swap "Welcome aboard" for a more formal "Glad to have you with us."

Click Save. This creates v1.2 as a new draft. It's not active and not released — so production traffic still serves the previous version.

3. Request review

On the v1.2 row in the Versions tab, click the Request review button (or the version menu → Request review).

The reviewer gets notified. The version is now in Review state — visible to reviewers in their queue.

4. The reviewer's view

Switching hats — you're now the reviewer.

Open the review

Notification → opens the version in diff mode. You see: the old version content (v1.1), the new content (v1.2), variables added/removed, author and timestamp.

Comment

Click any line to add a comment. Comments are threaded. The author gets notified when you reply.

Approve or request changes

Two outcomes:

• Approve — moves the version to Approved state. An approver can now publish.
• Request changes — sends it back to the author with your comments.

5. The approval gate

Once a version is Approved, an Approver clicks Publish. This is a two-step combined operation:

1. Set the version as active for the prompt.
2. (Optional, in the same dialog) Release to environments — check the boxes for development, testing, production, etc.

Publishing without releasing means "this is now the active version, but no SDK call will return it yet." That's a valid intermediate state, but the more common pattern is to release to at least development at the same moment.

6. Audit trail

Open Activity in the prompt's sidebar. You'll see:

v1.2 published by Alice · just now (released to: development)
v1.2 approved by Bob · 3 minutes ago
v1.2 review requested by Alice · 5 minutes ago
v1.2 saved by Alice · 8 minutes ago
v1.1 published by Alice · yesterday
...

Every state change is logged with actor and timestamp. This is the answer to "who approved this prompt?" — it's right there.

Common patterns