Runbook globals

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.

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:

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:

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 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:

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.

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.

Here's a full list of global variables that you can use in runbook templates, including the ones described above: