Skip to main content
Authoring builds a draft; this page covers what happens after: freezing a draft into an immutable version, reviewing it, and releasing it to an environment so your application serves it.

​
The Prompts list

Open a project and select Prompts. The list shows every prompt with its status, a band of summary cards (prompt count, active releases, prompt fetches over the last 24 hours, rollbacks over the last 30 days), and controls to search, filter by status or environment, and sort. A prompt’s status is one of:

​
Creating a prompt

From the Prompts list, choose New prompt and give it:
  • Display name: the human-readable name (at least 2 characters), for example Customer support router.
  • Slug: the lowercase, hyphenated identifier (letters, numbers, and hyphens; at least 2 characters), derived from the name until you edit it. Your application renders by this slug.
Name and slug must be unique within the project. Creating a prompt needs a developer, admin, or owner role. Continue creates the prompt and drops you into the editor to build its first version. See Authoring.

​
Versioning and publishing

Editing always happens on a draft. Publishing freezes it:
  1. Choose Publish in the editor.
  2. The confirmation explains the effect: the current version vN becomes an immutable, read-only version, and a fresh vN+1 draft is started from the same blocks, so you can keep editing without changing what’s published.
  3. Confirm to publish.
A published version can never be edited; that’s what makes a release reproducible. To change a published prompt, edit the new draft and publish again. Publishing an unchanged draft is a no-op; there’s nothing new to freeze. Publishing needs a developer, admin, or owner role. The other editor tabs work with this history:
  • Versions: the catalog of every version with its status, and the review panel below.
  • Diff: a block-by-block comparison between two published versions, defaulting to the latest against the previous one.
  • History: the version lineage over time, showing who changed what.

​
Reviewing a version

A version can be reviewed before it’s released. On the Versions tab a reviewer records a decision (Approve, Reject, or Request changes) with an optional note, and can later withdraw a rejection. Recording or withdrawing a review decision needs a developer, admin, or owner role.

​
Releasing to environments

Publishing makes a version available; it doesn’t deploy it. To serve a version, promote it to an environment on the Releases tab, which shows one release per environment.
  • Promote points an environment at a specific version.
  • Roll back returns an environment to an earlier version.
  • A release is either single (one version serves all traffic) or weighted, splitting traffic across versions for an A/B test or canary (for example, a 60/40 split across two variants).
Your application renders whatever version the environment it runs in currently points at, so a promotion or rollback changes the served prompt with no application redeploy. See Rendering prompts. Promoting, rolling back, and concluding an experiment need a developer, admin, or owner role.

​
Promotion policies

An environment can carry a prompt promotion policy that governs how versions move into it. A policy can require that a version was first promoted to a specific upstream environment, set a minimum dwell time before a rollback is allowed, restrict rollbacks within a lookback window, and require approval (optionally with separation of duties, so the promoter can’t be the approver). Managing these policies needs an admin or owner role.
Promotion policies are configured per environment. See Promotion policies and Release approvals for how they apply across a project’s environments.

​
Maintaining prompts

From each row’s actions menu in the Prompts list:
  • Edit opens the prompt in the editor.
  • Duplicate copies the prompt and its latest version into a new draft, named <name> (copy) with a -copy slug.
  • Archive hides the prompt from the default view without destroying it.
  • Restore brings an archived prompt back to active.
You can also change a prompt’s status and tags at any time, and select multiple prompts to act on them together from the bulk bar: set status, archive, restore, or duplicate the selection in one action.
The dashboard archives prompts rather than deleting them, so a prompt’s history stays intact and reversible. Prompts are removed permanently only when their project is deleted.

​
Permissions

Members don’t hold permissions individually; they hold a role, and the role carries the permissions. Prompts are project-scoped, so the role that applies is the one a member holds on the project. A workspace or organization role carries the same access down to every project beneath it. Each action maps to a permission, enforced server-side: See Roles & permissions for the full role model.

​
Next steps

Rendering prompts

Render a released version from your application.

Environments

Set up the targets you promote prompt versions to.

Release approvals

Require sign-off before a version reaches an environment.

Authoring prompts

Build the blocks, variables, tools, and config a version holds.