> For the complete documentation index, see [llms.txt](https://argos-ci.com/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://argos-ci.com/docs/learn/review-workflow/automations.md).
# Automations
An automation is a rule on a project: **when** something happens to a build, **if** it matches your conditions, **then** Argos notifies a channel. It replaces the person who would otherwise have to notice a build finished and relay it.
### Open the Automations tab
1. Open your project in Argos.
2. Select the **Automations** tab.
Automations are available on team projects, and the tab requires permission to view project settings.
### The three parts of a rule
Step
What it does
When
The build events that trigger the rule. A rule fires if any selected event happens.
If
Optional conditions that must all match for the rule to act.
Then
The actions Argos runs.
### When: build events
* **Build Completed** — the build finished processing, whatever its outcome.
* **Build Reviewed** — someone approved or rejected the build.
### If: conditions
Conditions narrow a rule so it only fires on the builds you care about. Every condition you add must match.
* **Build conclusion** — `no changes` or `changes detected`.
* **Build type** — `reference`, `check`, or `orphan`. See [build types](/docs/learn/platform-fundamentals.md#build-types).
* **Build mode** — `CI` or `monitoring`. See [build modes](/docs/learn/platform-fundamentals/build-modes.md).
* **Build name** — an exact build name, useful when your CI [splits builds](/docs/learn/how-to-guides/ci-pipelines/monorepos-setup.md).
* **Build branch** — an exact branch name, or a glob pattern such as `release/*`.
Each condition can be negated, so you can express "every branch except `main`" as a negated **Build branch** condition.
{% hint style="info" %}
Conditions are combined with AND. To notify on two unrelated cases — say, failures on `main` and anything on `release/*` — create two automations rather than one rule with both conditions.
{% endhint %}
### Then: actions
* **Post in Slack channel** — posts to a Slack channel. Requires the [Slack integration](/docs/learn/integrations/slack-integration.md).
* **Post in Microsoft Teams channel** — posts an adaptive card to a channel webhook. Requires the [Microsoft Teams integration](/docs/learn/integrations/microsoft-teams-integration.md).
* **Post in Discord channel** — posts an embed to a channel webhook. Requires the [Discord integration](/docs/learn/integrations/discord-integration.md).
If the destination isn't connected yet, the action offers the connection flow.
### Create an automation
{% stepper %}
{% step %}
#### Start a new rule
From the **Automations** tab, select **New Automation** and give it a name that says what it does — for example "Notify #frontend when main has changes".
{% endstep %}
{% step %}
#### Choose the events
Under **When**, select one or more build events.
{% endstep %}
{% step %}
#### Narrow it down
Under **If**, add conditions. Skip this step to act on every build that triggers the events.
{% endstep %}
{% step %}
#### Pick the destination
Under **Then**, choose an action and select the channel it posts to.
{% endstep %}
{% step %}
#### Test and save
Send a test notification to confirm the channel receives it, then save the automation.
{% endstep %}
{% endstepper %}
### Common recipes
Tell the team when a build needs review
**When** Build Completed · **If** Build conclusion is `changes detected` and Build type is `check` · **Then** notify your review channel.
This skips builds with no changes and skips reference builds, so the channel only hears about work that actually needs a human.
Watch a release branch only
**When** Build Completed · **If** Build branch matches `release/*` · **Then** notify your release channel.
Close the loop after review
**When** Build Reviewed · **Then** notify the channel where the build was announced, so the thread ends with the outcome.
### FAQ
Why didn't my automation fire?
Check the conditions first: they are combined with AND, so one non-matching condition stops the rule. Then confirm the event you selected is the one that actually happened — a build finishing raises **Build Completed**, not **Build Reviewed**.
Can an automation call my own endpoint?
Not today. Argos has no user-configurable outgoing webhooks — see [Integrations](/docs/learn/integrations.md#webhooks) for the alternatives, and tell us if webhooks would unblock your workflow.
Do automations apply to every project in my team?
No. Automations are configured per project, so a rule you create on one project doesn't run on the others.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## 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, and the optional `goal` query parameter:
```
GET https://argos-ci.com/docs/learn/review-workflow/automations.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
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.