> ## Documentation Index
> Fetch the complete documentation index at: https://docs.embedreach.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Overview

> Author automation templates and roll them out to your tenants

An **automation template** is an automation you define once and sync to your tenants. Each tenant gets its own automation built from the template.

## Editing steps

A template's steps live in `contents.actionData`. Every step has a `templateActionId`, which is how a sync matches a template step to the step it created in each tenant's automation.

| To | Do this |
| - | - |
| Edit a step | Send it with its existing `templateActionId`. Tenants' automations keep the same step, and a message step keeps its communication group. |
| Add a step | Send it without a `templateActionId`. Reach assigns one. |
| Remove a step | Leave it out of `actionData`. See [Removing steps](#removing-steps). |
| Reorder steps | Change their `index` values. Steps run in ascending `index` order. |

Always send back the `templateActionId` you read. A step sent without one is treated as new, so tenants' automations get a new step in place of the old one. Each step needs its own `templateActionId`: when you copy a step to add another, leave the ID out of the copy.

## Removing steps

Removing a step affects customers already in the automation, and adding the step back doesn't undo it:

* **Customers on the removed step stop.** A customer waiting at a wait step when a sync removes it stops there with an error. A customer whose message from a removed step is about to send still receives it, then stops. Neither continues to the steps that follow. Customers on other steps are unaffected and continue past the removed step.
* **Adding a message step back doesn't restore tenants' edits.** Once a sync has removed a message step, adding it back, even with its original `templateActionId`, gives tenants a new message built from the template.

## Updating a template

`PATCH /partner/automation-templates/{id}` replaces only the fields you send. Inside `contents`, each field you send replaces the stored one whole: sending `actionData` replaces the full step list.

A template's `contents.feature` can't change once it's created. A step's `type` can't change, except between the two wait-until behaviors (`wait_until_next_occurrence` and `wait_until_next_fixed_time`). To turn a step into a different kind of step, remove it and add a new one without a `templateActionId`.

To avoid overwriting someone else's edit, send the `ETag` from **Get Automation Template** as `If-Match`. If the template was saved after you read it, the update returns 412 and writes nothing; read it again and reapply your change.

## Rolling changes out

Saving a template does not update tenants' existing automations. Start a sync with `POST /partner/automation-templates/{id}/syncs`, then poll `GET /partner/automation-templates/{id}/syncs/{jobId}` until `status` is `completed` or `failed`. A finished sync reports `failed` if any tenant failed; check each tenant's entry in `tenants`.

Some changes reach tenants without a sync:

* **Categories** set with the Automation Template Categories endpoints apply to tenants' automations right away.
* **Tenants set up later**, such as new tenants on a template in `all` mode, get the latest saved template.
* **A sync already running** can apply a template saved after it started to the tenants it hasn't reached yet.

## Choosing tenants

`tenants` sets which tenants receive the template:

| `mode` | Who receives it |
| - | - |
| `all` | Every tenant, including tenants created later, except those in `excludedTenantIds` |
| `selected` | Only the tenants in `tenantIds`. An empty list means none, which keeps the template a draft. |

A sync deactivates the automation of a tenant that no longer receives the template, when the automation's current status allows it.

## What a sync changes

* **Trigger settings** are reset to the template's on every tenant automation that differs, including active ones. Changing a date-based template's date moves every tenant's scheduled date.
* **Messages a tenant edited** keep the tenant's version. Template changes to that email or SMS body do not reach them.
* **One-time automations** that are scheduled or already sent are left unchanged. The sync still reports those tenants as `completed`.
* **Segments** the template uses are created on each tenant, and reactivated if the tenant deactivated them. A tenant that cannot receive one of them fails to sync; check its entry in the sync's `tenants`.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.