# Run a Playbook

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.

## 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.

{% hint style="info" %}
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.
{% endhint %}

## 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 AI 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.

{% hint style="info" %}
Use a **Webhook** Trigger when an external system should start a Playbook programmatically.
{% endhint %}

## 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.

{% hint style="warning" %}
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.
{% endhint %}

## 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.

## 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.

{% hint style="info" %}
A Playbook that monitors data commonly uses Memory to avoid recommending the same item again within a configured window, such as 60 days.
{% endhint %}


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.airops.com/actions/playbooks/run-a-playbook.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.