Run a Playbook

Run Playbooks manually, from Grids, or with Triggers

You can run a Playbook manually from the editor, from a Grid, or automatically with a Trigger. Each run creates a Session with execution details and Artifacts.

Run manually

Use a manual run when you are testing a Playbook or running it for a single use case.

1. Open the Playbook editor.
2. Click Run Playbook.
3. Provide any required Inputs.
4. Review the Session output and Artifacts.

Runs started from the Playbook editor use testing tasks before production tasks. Each workspace has 50,000 free testing tasks per month that can be used for Workflow and Playbook testing. If your workspace uses all testing tasks, AirOps uses production tasks for additional editor runs. You can review testing task usage in the Usage tab.

Run from a Grid

Use a Grid when you want to run a published Playbook across rows of structured data.

1. Open the Grid.
2. Click + Add Column.
3. Select the Playbooks tab.
4. Search for the Playbook.
5. Map Grid columns, static values, or Brand Kits to the Playbook Inputs.
6. Run the Playbook for one row or in bulk.

When a Playbook runs from a Grid, it uses the version and Input mappings configured on that Grid column. Edits you make in the Session chat apply to the Artifacts, not to the Playbook. To change the Playbook itself, open it in the editor.

See Run Playbooks in the Grid for version selection, bulk runs, Session status, and Artifact review.

Run automatically

Use a Trigger when the Playbook should start on a schedule, from an external event, or from an AirOps signal.

Trigger types include:

• Schedule: Run on a recurring cadence.
• Webhook: Run from an HTTP request.
• Monitor: Run when Parallel Web Systems detects a condition from your monitoring query.
• AEO Insight: Run when an enabled Insights threshold is met.

Triggered runs land in Run History. Runs that need Human Review also appear in the Inbox.

For Trigger setup, version settings, and webhook payload examples, see Playbook Triggers.

Versions and Input changes

Grid columns and Triggers can use Default or a pinned Playbook version.

• Default follows the current published version.
• Pinned keeps using the selected version until you change it.

If a new Playbook version changes Inputs, update any Grid column mappings and Trigger Input configuration before running at scale. New required Inputs without mapped or configured values can make runs fail validation or be skipped.

Review Sessions

Every run produces a Session. A Session contains:

• The full execution log.
• Inputs used for the run.
• Every Artifact the Playbook produced.
• Human Review status, when the Playbook includes review blocks.

Sessions are visible in Run History from the top-right of the Playbook editor and in the Inbox when review is required.

Collaborate on Artifacts

Artifacts support comments, suggestions, mentions, version history, and AI-assisted edits. Use these controls when a Session output needs review before publishing or downstream use. Edits affect the Artifact for that Session, not the Playbook instructions.

See Artifacts for the full collaboration, recovery, stable-link, and Grid workflow.

Interrupt or rerun a Grid Session

In a Grid, Playbook cells show the current Session status. You can open the Session from the cell, interrupt a queued or running Session, and rerun terminal Sessions. If a Session ran on an older Playbook version, the cell shows a warning so you can rerun it on the current version.

Use two Playbooks for monitoring and action

Many Playbook setups use a two-Playbook pattern.

The first Playbook monitors data and finds work for you. It can run on a Trigger, scan AirOps Insights, identify opportunities, and push them to a Grid with the AirOps MCP, such as URLs to refresh or prompts to target.

The second Playbook takes action on those rows and produces the output. You can run it manually or as a Grid action on the row produced by the first Playbook, such as drafting a blog post for a target prompt or refreshing an existing page.

One Playbook finds the work. The other Playbook does the work and gets you to an output. You can use either pattern alone, but they are commonly composed.

A Playbook that monitors data commonly uses Memory to avoid recommending the same item again within a configured window, such as 60 days.