Runbook globals
Values available to use when executing a template for a runbook
Airplane supports JS templates for specifying various runbook fields
including block inputs and start conditions. These
allow, for instance, a block to use the output of a previous block as an input or only run if a
top-level runbook parameter was set to a particular value.
The sections below discuss the global objects that you can access inside these templates.
Parameters
You can define top-level parameters in the "Define" section of a runbook.
These can be strings, integers, numbers, or more complex input types like dates or files.

All runbook parameters are stored in a global object called
params
. You can use this object along
with the parameter's slug to refer to any parameter within a template. In this example,
{{params.user_email}}
will be used to refer to the "User email" parameter from the screenshot
above:
Config variables
You can define config attachments in the "Build" section of a runbook. These
allow you to reference config variables you've added in any block of the runbook.

Similar to parameters, any attached configs are stored in a global object called
configs
. You can
reference the config by its name in any templated field. In the example below,
{{configs.sender_email}}
refers to the sender_email
config variable and is used in an Email
block:
Block output
You can also take the output from any block and pass it into future blocks. Each block has its own
slug that can be edited by clicking the pencil icon to the right of the block name. To refer to a
block's output, use the expression
block_slug.output
. For example, if your block has the slug
sql_query
, then you could access its output with sql_query.output
. The slug of a block is
displayed to the right of the name at the top of the block.If you're using a Task block created with Python, JavaScript, Shell, or other kind of custom code
builder, use Output to render them in a way that can be accessed from runbook JS
templates.
Below is an example of a block that generates an output table (representing a JavaScript array)
called
response_data
. This table has one row with three columns. The next block, a Slack message,
can reference one of the values in the output with an expression like:
{{block_slug.output.response_data[0].user}}
In this expression,
block_slug.output
refers to the entire output object. response_data
is the
specific object outputted within here (there can be multiple output objects). [0]
refers to the
first row of the output array (there's only one row in this example, but there can be multiple). And
then user
refers to the value of the user field in that row.
If you want to examine the output of a block as raw JSON, click the "JSON" tab above the output:

SQL block output
SQL blocks or SQL-based task blocks will display output in a table that can be referenced in
subsequent blocks via
output
. This works the same way as above: use block_slug.output
to refer
to the output, and then reference the child objects, rows, and values to get to the value you want.By convention, the output of all SQL select blocks will be an object with keys such as
Q1
, Q2
,
etc. The first select statement's results will be included as a list of rows in Q1
, the second
query in Q2
, and so on.Therefore, you'd refer to the output of a SQL block as something like
{{block_slug.output.Q1[0].field_name}}
, as shown below:
Block inputs
You can refer to the input used by any block in a future block.
In the example below, we send an email to an individual followed by an API call with the same
individual's email. Rather than copy and pasting their email address, we can refer to the
recipients
parameter of the email
task with an expression like
{{email.input.recipients[0].email}}
In this expression,
email.input
refers to all of the parameters on the task.
Start conditions
Runbook start conditions don't require
{{
notation for templating.
You can enter JavaScript directly into a start condition since all start conditions must be
JavaScript expressions that evaluate to either true
or false
.
Globals reference
Here's a full list of global variables that you can use in runbook templates, including the ones
described above:
Name | Description |
---|---|
{{params}} | An object, keyed by parameter slug, containing the runbook's parameter values. |
{{configs}} | An object, keyed by config name, containing the runbook's config attachments. |
{{<block_slug>.output}} | The output of the block with slug, block_slug . The format of this value matches what is shown in the JSON output tab. |
{{<block_slug>.input}} | The input used by the block with slug, block_slug . The format of this value depends on the type of the task. |
{{session.id}} | The Airplane-generated ID of the session. |
{{session.url}} | A URL that opens the session. |
{{session.name}} | The name of the session. |
{{session.creator.email}} | The email of the person running the runbook. |
{{session.creator.name}} | The name of the person running the runbook. |
{{session.creator.id}} | The Airplane-generated user ID of the person running the runbook. |
{{block.id}} | The Airplane-generated ID of the current block. |
{{block.slug}} | The slug of the current block. |
{{runbook.id}} | The Airplane-generated ID of the associated runbook. |
{{runbook.url}} | A URL that opens the associated runbook. |
{{runbook.name}} | The name of the associated runbook. |
{{env.id}} | The id of the environment context of the session. For information on environments, see Environments. |
{{env.slug}} | The slug of the environment context of the session. |
{{env.name}} | The name of the environment context of the session. |
{{env.is_default}} | true if the environment context of the session is the team's default environment. |