Publish automation changes safely

Publish email automation changes without surprising the contacts already in the flow: read what changed since the live version, decide where those contacts continue, and let the pre-publish checks stop a broken version before it goes live.

Before you begin

• You need automations:publish, a sensitive permission that the Owner, Admin and Editor roles hold. Restoring an old version as a draft needs only automations:edit.
• A flow with a Send SMS, Send push or Send WhatsApp step also needs sms:send, push:send or whatsapp:send. Without it, publishing goes to approval by a member who holds it.
• Two workspace settings change what publishing does. A member with workspace:manage sets them:
  • In Settings › , then Approvals, the rule Publishing an automation also requires approval sends every publish for approval. While it is off, publishing is only logged. See require approval for risky sends.
  • In Settings › , then General › , then Accessibility, the policy is Warn or Block. With Block, serious accessibility issues in the flow’s emails stop publishing. See check email accessibility.

Publish a new version

1. Open the flow from Automations. The header shows the live version and its date, such as Live · v3 since 11 Oct, and how many changes the draft has that the live version doesn’t.

2. Select Publish in the header; the button carries the draft’s version, such as v4. ReputeCast saves the draft first, then opens the publish dialog.

3. Read the diff. The dialog counts the changes since the live version was published, with the date and who published it, and lists them under the version diff, such as v3 → v4. Each row is Added, Changed or Removed, with what it means for contacts. In the demo workspace, the Welcome series draft reads:

   • Added: an A/B split after step 2, 50 / 50, with two new email steps that pass the content checks.
   • Changed: the delay before step 2 goes from 1 day to 2 days; contacts already waiting keep their timer unless you move them.
   • Removed: a webhook that had returned 404 since 8 Oct, with its failed calls still in the webhook log.

   The last row, Unchanged, lists what stays the same. Moving steps on the canvas is never a change. A flow’s first publish has no diff: the dialog says every step is validated before it goes live.

4. Decide what happens to the contacts in the flow. Under Contacts already in the flow the dialog says how many contacts are in the flow right now and offers two choices:

   • Let them finish on the live version (the default, marked recommended). New contacts start on the new version; contacts already in the flow finish on the old one, so nobody gets a step twice or skips one. The old version retires when its last contact leaves, and the dialog estimates when, such as “about 5 days”.
   • Move them to the new version at their current step. Each contact continues from the same step in the new version. A contact on a removed step goes on to the next step that still exists; a contact in a changed delay gets the new delay, counted from when they reached it. The dialog spells out the effect, such as “612 contacts waiting before step 2 would get the 2-day delay”.

5. Read the Pre-publish checks. Green passes, amber warns, red blocks:

   Check	Blocks publishing
   The Automations route: healthy, on its fallback, or no healthy provider (emails wait until one is)	No
   Every email step passes the Send Readiness content checks	Yes, when any email fails
   No step references a deleted list, tag, form, email or provider	Yes
   Every branch and A/B split path is connected	Yes
   Any other problem from Before you publish	Yes
   Text steps: quiet hours, and whether a sender can text each country	No
   Language versions that are outdated	No
   Serious accessibility issues, one badge per email step, such as “Step 3 B: 1 serious issue, button contrast”	Only with the Block policy; the live version keeps sending

   While a check blocks, the publish button is disabled and says why.

6. Publish. Select the publish button with the new version number. The version goes live, a message confirms it, and you return to the list. Save draft only keeps the draft without publishing, and Back to canvas closes the dialog.

Note

Publishing goes to approval instead of live when the workspace rule Publishing an automation also requires approval is on, when an agency client’s sign-off covers automations, or when a channel step needs a send permission you lack. The message then says the version is waiting for approval and names the approvers: members with campaigns:approve other than you, who also hold the missing send permission when that is the reason. Once approved, ReputeCast publishes that version with the choice you made in step 4. If the draft changed after the approval, it is not published: you get a notification, and publishing again asks for a new approval.

Restore an earlier version

1. In the flow’s header, select Version history. Each published version shows its date, who published it and what it changed. The live version shows how many contacts are in it; an older one is retiring while contacts still finish on it, or retired with the date it emptied.

2. To see what the draft changes, select Compare: it shows Changes since the live version.

3. Next to the version you want back, select Restore as draft. When the draft has unpublished changes, ReputeCast asks whether to replace them: select Replace or Keep.

4. The old version is now the draft, under a new version number. Check it on the canvas and publish it like any other change.

Pause and resume a flow

1. In a live flow’s header, select Pause. The dialog says how many contacts are in the flow.

2. Optionally enter a Reason of up to 200 characters, such as “beta is full”; the automations list shows it on the flow’s row. Select Pause automation, or Keep it running to cancel.

   While the flow is paused, no new contacts enter. Contacts in it stay where they are, delays keep counting, and nothing is sent.

3. To restart it, select Resume. New contacts enter again and waiting steps continue; delays that ended during the pause run at once.

Check that it worked

• The header shows the new version as live with today’s date, and the list’s row says it was published today.
• In Version history, the new version shows as live and, if you let contacts finish, the old version shows as retiring with the number of contacts still in it.
• A paused flow shows Paused on its row in the list, with who paused it and the reason.
• Every publish, approval request, pause and resume is in the workspace’s audit log.

Troubleshooting

• The publish button is disabled and says there is nothing to publish. The draft is the same as the live version, or it only moves steps around on the canvas. Change a step’s settings or connections to publish.
• Publishing fails with “The draft is now v5. Review the changes again before publishing.” Someone saved the draft after you opened the dialog. Close it and open it again to review the new diff.
• A red check says emails fail content checks. Open the email step, fix the email in the composer (the check names the first problem, such as a missing unsubscribe link) and publish again.
• Publishing is blocked by the accessibility policy. The blocking message names each issue and step. Fix them in the emails, or ask a member with workspace:manage to set the policy to Warn. The live version keeps sending in the meantime.
• Publishing fails although your workspace requires approval. Approval needs a member other than you with campaigns:approve (and the missing send permission, when that is the reason). Give it to another member’s role in Settings › , then Roles; authors can’t approve their own request.
• You got an “Approved, but not published” notification. The draft changed after the approval, or a check now fails. Fix the flow and publish again to request a new approval.
• Pause and resume are disabled. They need automations:publish. Only a live flow can be paused, and only a paused one resumed.

Related

• Build automations covers the canvas, the draft and the stats.
• Triggers and steps lists the settings each step is validated against.
• Require approval for risky sends sets the approval policy and approvers.
• Check email accessibility explains serious issues and the Warn and Block policies.
• Permissions and roles lists automations:publish and the channel send permissions.