Prompt Library

The Prompt Library is a centralized catalog of reusable prompt templates. Instead of re-writing the same instructions across every LLM field, you save a prompt once and link to it from any number of workflows. The library tracks versions, usage, variants, and who created what.

When to use the library

Use the library when you want to:

• Reuse the same instructions across multiple LLM fields or workflows.
• Keep prompts under change control (version history, usage tracking).
• A/B test alternative phrasings side-by-side.
• Share a canonical "system message" template across a team or the whole platform.

Skip the library when a prompt is one-off, highly dependent on a specific workflow's upstream fields, or still being iterated on. You can always promote an inline prompt to the library later via Save to library.

Accessing the Prompt Library

Open Prompts in the left sidebar. The list page shows every prompt you can access, with columns for Name, Description, Role, Scope, Version, and Last Updated. Name, Version, and Last Updated are sortable; search filters by name.

The detail page's left sidebar adds Filter by Scope, Sort (Name, Created, Last Updated, Version), Show Archived, and a scoped search for jumping between prompts.

Prompt structure

Every library entry has the following fields:

Role

Each prompt is tagged as either User or System. The role doesn't change how the prompt is stored — it controls where it shows up in the Pipeline Builder's LLM field picker:

• User — offered for the user prompt slot of an LLM-Response field. This is the task-specific request the model receives.
• System — offered for the system message slot. The platform default system instructions are always sent; a linked system-role library prompt is appended to them for that field (or for all fields in a group, if used at the group level). There is no way to replace the platform default.

Role is separate from Scope. A User prompt can still be Organization-scoped, and a platform-curated System-scoped prompt can have either role.

When you click Save to library from inside a workflow, the new entry is automatically tagged with the role of the slot you saved from.

Creating a prompt

Two entry points:

• From the Prompts page — New Prompt opens a form for Name, Role, Description, and Prompt Text (see Variables for dynamic values). Saves as version 1.
• From inside a workflow — while editing an LLM-Response field in Use custom prompt (or its system-message equivalent), click Save to library. The new entry inherits the role of the slot you saved from, and the field is re-linked to it at version 1.

Variables

Prompt templates can include variables that resolve to upstream field values at runtime. Variables are inserted from the workflow's template editor, not typed by hand: in template mode, type {{ (or click Insert Field) to open a field picker and insert a purple variable chip. In the Form Builder preview, unresolved chips stay styled as chips; resolved values appear with a dotted underline you can hover to see the source field. See LLM-Generated Fields for the full variable-insertion UX.

Variables are workflow-scoped

A variable is bound to a specific field in a specific node of the workflow it was created in, and that binding travels with the saved prompt text:

• A prompt saved from workflow A carries workflow A's field bindings.
• If you reuse that prompt in workflow B where those fields don't exist, the unresolved variables render with a warning style in the editor and resolve to an empty string at runtime (the rest of the prompt still runs).
• For prompts you plan to share across workflows, leave the dynamic parts out of the library entry and re-insert variables per-workflow after linking.

The Prompt Library detail page uses a plain Markdown editor, so bindings from the originating workflow appear here as raw placeholder text. Edit variables inside the target workflow's template editor, not on the library detail page.

Using a prompt in a workflow

Prompts are linked from an individual LLM-Response field (or a field group's shared LLM settings).

On an LLM field, open the Prompts popover and set Prompt Source to Use prompt from library. The picker lists prompts whose role matches the slot (user prompts for the main slot, system prompts for the system-message slot); expand a row to preview, then check it to link. Linking captures the current version and text.

System prompts link the same way under the field's System section (radio: From prompt library), or at the group level via the System chip in a shared LLM group. See LLM-Generated Fields for setting a field's Data Source to LLM.

The prompt text is not editable while linked

Library mode shows only the picker — no inline editor. To tweak the text for one workflow without changing the library entry, switch Prompt Source back to Use custom prompt. This detaches from the library (clears the reference) but preserves the current text as a starting point for editing. Optionally Save to library afterward to capture the edit as a new entry.

To change what the field is linked to, re-open the picker and select a different prompt or variant. Re-selecting overwrites the stored prompt text with the newly chosen entry's content.

Pinned vs. unpinned versions

When you select a prompt in the picker — or save a new one via Save to library — the field is pinned to the version shown at that moment. Editing the library prompt afterward does not change pinned references; the workflow keeps running against the version it was pinned to until you re-select.

A small number of references can be unpinned (prompt ID stored without a version). These are rare and typically come from legacy data, imported workflows, or hand-edited configurations. Unpinned references follow the prompt's current head version at runtime. The prompt detail page's Version History shows which workflows reference each version and whether the reference is pinned.

To move a pinned field to a newer version, re-open the picker and re-select the prompt.

Variants

Variants are alternative versions of the same prompt, useful for A/B testing or maintaining domain-specific forks.

Creating a variant

On a parent prompt's detail page (variants themselves cannot be forked), use the Variants card's Create Variant action. The prompt text is pre-filled from the parent; give the variant a name and edit as needed.

The variant starts at its own version 1 and records which parent version it was Forked from (shown in the badge row and metadata footer).

Variant rules

• Variants are one level deep — you cannot create a variant of a variant.
• You cannot fork an archived parent. Restore it first.
• A variant inherits the parent's role (user/system); role is not selectable in the variant dialog.
• Variants of Organization prompts stay Organization-scoped. System prompts do not expose a Create Variant action — to customize one, copy its text into a new Organization prompt.
• A parent with any variants (active or archived) cannot be hard-deleted — a delete request will archive it instead.

Using variants for A/B testing

In the Prompt Library picker (inside a workflow LLM field), variants appear indented under their parent. Checking more than one prompt or variant creates a compare prompt variants configuration:

• The form builder generates sibling LLM fields — one per selected variant — grouped under the same field.
• When a task runs, each variant is sent to the model independently, producing parallel outputs you can compare.
• Each selected row gets a label input where you can rename the field suffix used in the form.

To collapse back to a single prompt, uncheck all but one in the picker. The sibling fields are removed automatically.

Scope and visibility

Every prompt has a scope that determines who can see and edit it.

System prompts appear in your library and picker alongside Organization prompts. To customize one, copy its text into a new Organization prompt.

Who can do what

The Edit, Delete, and Create Variant actions only appear on the detail page when you have permission for that prompt. Viewers and Contributors cannot open the Prompts page or the library picker in workflows — if your team includes users at those roles who need to reference library prompts, assign them a higher role or link the prompts via a pre-built workflow.

Versioning

Prompts are versioned so that references can be pinned and changes are auditable.

• A new version is created only when prompt text or role changes. Changes to name or description update the record in place without bumping the version.
• Each version snapshot is immutable and preserves the full prompt text (plus the name and description at the time of save).
• The detail page's Version History card lists every version, newest first. Expand a version to see the prompt text and which workflows reference it.
• Version numbers are monotonically increasing per prompt. There is no branching — variants serve that purpose.

What happens when I save an edit?

Saving edited prompt text or role increments the version, adds a Version History entry, and makes the new text the head. Pinned references keep running against their old version; unpinned references pick up the new head on the next task run.

Usage tracking

The prompt detail page shows exactly where the prompt is referenced.

• The hero card shows a total workflow count.
• The Version History card breaks usage down per version:
  • Referenced by workflows — workflows that use this specific version (or, for the head, any unpinned references). Status badges indicate archived, draft, or deleted workflows.
  • Via variant — workflows that reference a variant forked from this version, rolled up under the parent version.
• Each workflow row links directly into the Pipeline Builder for that workflow.

Only workflows you have access to are listed.

Archiving and deletion

Clicking Delete runs a smart-delete:

Archived prompts:

• Are listed as Archived in the list/sidebar when Show Archived is enabled.
• Cannot be edited until restored.
• Cannot be forked (you cannot create a variant of an archived parent).
• Can be restored in one click from the detail page (Restore button).

Restoring returns the prompt to active state without changing its version or content.

Limits

Common mistakes

• Typing {{placeholder}} by hand. Hand-typed placeholders are sent to the model as literal text. Use the workflow template editor's {{ shortcut or Insert Field.
• Expecting name/description edits to bump the version. They don't — only prompt text and role do.
• Reusing a prompt with workflow-specific variables in another workflow. Those bindings don't resolve in the new workflow and are sent as empty strings.
• Assuming all references auto-update after an edit. Pinned references stay on the selected version until re-linked.
• Trying to fork a variant or hard-delete a prompt that has variants. Variants are one level deep; a parent with any variants (active or archived) always archives instead of hard-deleting.

Example: reusable article summarizer

1. Create a new prompt named Article Summarizer with role User and prompt text:

   Summarize the following article into five concise bullet points.
   Preserve key facts, names, and numbers.
   
   Article:

   Leave variable insertion for later — variables are specific to each workflow that uses the prompt.

2. In a workflow with an LLM field, set Prompt Source to Use prompt from library and select Article Summarizer. The field now carries a pinned reference to v1.

3. To inject an upstream field (for example, the article body) as a variable, switch Prompt Source to Use custom prompt to detach. The detached copy keeps the library text as a starting point — enable template mode and use {{ to insert the field as a variable chip. Optionally Save to library to capture the workflow-specific version as a new library entry.

4. Save the workflow. When a task runs, the model receives the template with the article body substituted in.