Editing steps
A template’s steps live incontents.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 withPOST /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
allmode, 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.