Skip to main content
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. 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: 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.