# Chained automations

> For the complete documentation index, see [llms.txt](https://www.jetbrains.com/help/air/llms.txt).

A chain is a multi-step workflow built from automations: when a run of one automation finishes, the next automation starts and receives that run's results. Each step stays a separate automation with its own instructions, repository, and triggers, so you can build, test, and change it on its own.

For example, a nightly automation triages the failing tests and reports what it found. When it finishes, a second automation fixes the tests it named and pushes the fix to a new branch. When that one finishes, a third automation gets the name of that branch, checks it out as its instructions say, reviews the fix, and reports the result in a [notification](automation-notifications.html).

```PLANTUML
        
@startuml
skinparam shadowing false
skinparam defaultTextAlignment center
left to right direction

rectangle "Trigger" as trigger
rectangle "Automation 1" as a1
rectangle "Automation 2" as a2
rectangle "Automation 3" as a3

trigger ..> a1 : "starts"
a1 --> a2 : "finishes,\npasses results"
a2 --> a3 : "finishes,\npasses results"
@enduml
        
```

## How a chain works

* A chain is set up on the receiving end. The next automation gets an Automation finished [trigger](automation-triggers.html) that names the automation it waits for. The automation it waits for doesn't know about it, so you can add a step to a chain without editing the steps before it.

* The trigger fires only when a run finishes successfully.

* Each automation in the chain runs with its own configuration: its repository, branch, instructions, and [change handling](automation-triggers.html#automation_trigger_change_handling), which can be any option. The automations in a chain may work on another repository or don't have a repository at all.

* A step can be done by a person instead of an agent – see [Automations done by a person](person-automations.html).

* The next run's page names the automation that started it and links to that run, so you can follow the chain back step by step.

## Set up a chain

A project automation can wait for automations of the same project, and a personal automation for your other personal automations.

Procedure: Start an automation when another one finishes

1. [Create](create-automation.html) the next automation, or open an existing one for editing.

2. In Triggers, click Add Trigger and select Automation finished.

3. In the Automation field, select the automation to wait for.

![An Automation finished trigger row with the automation to wait for, the checkout branch, and Push to new branch selected, next to the open Add Trigger menu](images/chained-automations-add-trigger.png)

4. Set the branch and what to do with the changes, the same as for any other trigger.

5. In Instructions, tell the agent what to do with the previous run's results – see [Use the previous run's results](#use_previous_results).

6. Save the automation.

To start an automation after any of several automations, add an Automation finished trigger for each of them. Each trigger fires on its own.

An [automation template](automation-templates.html) keeps this trigger without an automation. You select one when you create an automation from the template.

## Use the previous run's results

The next automation's agent receives the results of the run that started it as input:

* The summary and links the run reported

* The name and link of its repository, and the branch it started from

* The name of the branch it pushed, if it pushed one

* A link to the run

For an automation with several repositories, this covers only its primary repository.

This input is text. It doesn't change what the next run checks out: the run clones its own repositories and starts on the branch its trigger sets. If the previous automation works on a different repository, the next run gets that repository's name and branch, but not its code. To work on the code, add that repository to the next automation as an [additional repository](create-automation.html#multi_repo_automation).

Say in the Instructions which part of the input to use and how, for example:

* Fix the tests named in the previous run's summary.

* Check out the branch the previous run pushed and review the changes.

The summary is what the previous automation reported, so write that automation's instructions with the next step in mind: ask it to list what the next step needs, such as the test names or the files it changed.

## What stops a chain

A chain stops at a step that doesn't finish successfully. A run that fails or is stopped doesn't start the next automation. After you fix the cause, [repeat the run](automation-run-results.html#rerun_automation_run) to continue.

A chain also stops when:

* The next automation is [paused](manage-automations.html#pause_resume_automation). It doesn't start while paused.

* The automation a trigger waits for is deleted. The trigger shows Automation not found and never fires again.

Nothing stops a chain that loops back on itself, for example, two automations that start each other. It keeps starting runs until you pause or edit one of them.