Scenarios are reusable, administrator-managed workflows that turn a repeated workspace action into a controlled sequence of steps. Use them when a team wants one button to run the same agent prompt, pause for the same human review, call the same nested workflow, and use the same runtime resources every time. A scenario is not just a saved prompt. It uses a template, installation, and run-time snapshot model:
Running scenarios keep snapshots of the template version, compiled workflow, runtime mappings, runtime presets, and launch inputs that were used at start. Later edits to templates or installations affect future runs, not runs that already exist.

​
Who Can Manage Scenarios

Scenario management uses the same organization-admin boundary as workspace runtime presets. Admins use Settings → Scenarios. The section is split into two subtabs:

​
The Most Important Boundary

Flow builder v1 is intentionally linear. Every scenario is a single ordered chain:
The visual builder does not expose manual edges. The backend also rejects non-linear dependency graphs. This means a scenario can feel like a workflow builder, but it still behaves as a simple, predictable chain.

​
Quick Start: Install and Configure a Scenario

1

Open Templates & Builder

Open Settings → Scenarios → Templates & Builder. Select the organization and host that should provide scenario templates.
2

Choose a template

Pick a template from Template library. The Versions and flow preview panel shows the template version, checksum, and a visual preview of the linear flow.
3

Install the version

Click Install. Jaidu creates an installation that is disabled and hidden from the chat toolbar by default.
4

Configure the installed copy

Switch to My scenarios, open the installed scenario, then use Configure launch to rename the installed copy, map runtime requirements to organization runtime presets, and add launch defaults.
5

Publish it to chat

Use Publish to review the checklist, refresh readiness if needed, enable Allow new runs, then turn on Show in chat toolbar once backend preflight says the scenario is runnable.

​
What You Can Influence

The table below is the shortest way to understand what each control changes.

​
Templates & Builder

Use Templates & Builder for template work. Template work is about what a scenario does. It is separate from installation work, which is about whether a saved scenario can run in your organization or workspace.

​
Template Library

The library shows templates returned by the selected host and organization. First-party templates are seeded by the host. A template can have multiple versions.
Installing a template does not make it runnable immediately. New installations start disabled and toolbar-hidden so an admin can configure runtime setup and defaults first.

​
Edit Installed Scenarios Safely

Use My scenarios → Edit flow when you want to change a downloaded or installed scenario. The action opens an editable copy in Templates & Builder. Saving the result creates a new private immutable version. It does not mutate the source installation, source version, or active runs. When the source is an installed scenario, the editor can offer these save options:
Replacing an installed scenario still preserves existing run snapshots. The replacement starts disabled and hidden from chat until readiness passes.

​
Flow Board Builder

The builder is the main no-JSON path for building organization-private linear templates. It looks like a Zapier/Activepieces-style board, but it still writes a strict v1 linear manifest. Start and Done are fixed boundary nodes; only the step cards between them can be inserted, reordered, or removed. The board deliberately does not store node positions in the manifest. Zoom, canvas background, plus popovers, and drag handles are authoring UI only.

​
Launch Inputs

Launch inputs define the fields a scenario can receive at start time. The visual editor supports the common case: string fields with a key, label, and required flag. Prompts can reference launch inputs with template placeholders, for example:
Keep input keys stable after a template is in use. If you rename objective to goal, update every prompt and scenario-call binding that referenced objective.

​
Step Types

A v1 scenario can contain only these step types.

​
Agent Prompt Runtime Requirements

An agent prompt step can either use the workspace default runtime or require an isolated runtime preset. The advanced runtime resource fields define the resources expected by every runtime requirement key in that draft: For isolated requirements, backend preflight checks that the mapped preset has the required resources and does not include unexpected extra resources.

​
Scenario Call Input Bindings

A scenario call passes launch inputs from the current scenario into the nested scenario. Example:

​
My Scenarios

Use My scenarios for configuration of scenarios that already exist in your organization or workspace. Installed configuration answers: Can this scenario run here, and with which resources/defaults?

​
Installed Scenario Detail

Each installed scenario opens into a detail panel with five views. Flow recipe editing stays separate. Use Edit flow to fork the immutable source version into Templates & Builder.

​
Scenario Detail Controls

​
Runtime Setup

Runtime setup connects template requirements to organization runtime presets. A mapping does not create skills or MCP servers. It selects a preset that should already contain the resources required by the template. See Workspace Runtime Presets for how runtime presets select skills and MCP servers.

​
Default Launch Inputs

Launch defaults are saved on the installation. They provide fallback values for future runs. For installed scenarios launched from workspace chat, Jaidu builds launch inputs from the installation defaults and the current workspace/chat context. The launch preview shows the exact default and launch input object before you start.

​
Backend Preview and Readiness

The configuration panel shows a backend preview because the server is the source of truth for runtime compatibility.
Saving runtime setup may temporarily disable the installation and hide it from the toolbar until backend preflight validates the new configuration.

​
Toolbar Visibility Rules

An installed scenario appears in the workspace chat toolbar only when all required conditions are satisfied. The My scenarios tab also shows Toolbar-hidden scenarios so admins can see why an installed scenario is not appearing in workspace chat.

​
What Changes Affect Future Runs

​
Troubleshooting

Check Settings → Scenarios → My scenarios. The installation must allow new runs, toolbar visibility must be on, and backend preflight must be OK and runnable. Also confirm that the installation is not scoped to a different workspace.
Toolbar visibility requires allowed runs and runnable backend preflight. Open Configure launch, fix runtime setup or default inputs if needed, refresh readiness, then try again from Publish.
The template has an agent prompt with an isolated runtime requirement key. Map that key to an organization runtime preset in My scenarios → Configure launch.
The mapped runtime preset does not contain the canonical resource required by the template. Edit the runtime preset or choose a different preset.
Flow editing creates a new private version. Install or replace the installed copy from the save options, then configure and publish the resulting installation. The source version remains immutable.
Confirm that the launch input key exists, the default launch input has a value, and the prompt uses the same key, such as {{ input.objective }}.
The import path is still constrained to v1 linear manifests. JSON with DAG, fan-out, fan-in, unsupported step types, invalid dependencies, or invalid runtime requirements is rejected.