Marketing workflow version control: Use a stable workflow ID and version for each release; Record change details, dependencies and recovery route; Revert workflows via revision history with Super Admin access
Image: Automation Marketing Lab

Automation Builds

Marketing workflow version control

Keep marketing automation changes traceable with release records, dependency checks and a recovery route.

Marketing workflow version control lets an operator identify the rules running now, explain a change and recover a known configuration. Keep a release record alongside the platform’s revision history. Connect each release to its purpose, affected assets, checks and recovery route.

Give each release an identity

Use one stable workflow ID in its name, change log and incident notes. Assign a new release version when an edit could change who enters, the path taken, the action performed or its timing.

Record the old and new versions, owner, change time and effective time. A date alone may not distinguish several edits made on one day.

Release record / What to capture

Scope
Workflow ID and campaign or process served
Difference
Trigger, condition, action, timing or setting changed
Reason
Approved request and expected outcome
Dependencies
Forms, segments, messages, properties and connected systems affected
Check
Expected cases, observed results and gaps
Release
Activation time, monitoring owner and recovery route

This register is an operating practice; not every platform provides it. A revision screen may show a configuration change without recording its business reason or approval evidence.

In HubSpot, revision history is listed chronologically, with the newest change first. You can filter by date range, event type or user, then view a selected revision’s workflow settings as they were at that time. Super Admin or Workflows permissions are required to use the workflows tool.

A revision attributed to an Unknown user may have been made by the HubSpot system. Match a platform entry to an operator’s release note with that possibility in mind. The revision history’s user field is useful evidence, but it may not identify a person for every change.

Include the working dependencies

An automation’s behaviour can depend on assets outside its diagram. A branch may read a segment or property; a send action may use an email edited separately; a webhook may call an external service. Record the identifiable state of each dependency that matters to the release. Restoring the workflow definition alone may otherwise leave it using a changed audience or message.

HubSpot’s workflow details page provides action logs and enrolment history for reviewing events that have occurred in the workflow. Use revision history separately to review what was configured at a particular time.

HubSpot retains workflow action log data for 90 days and historical enrolment data for six months. Keep a separate release record where longer or fuller evidence is needed.

For workflows that change CRM properties, HubSpot also provides a way to review and revert property changes made by a specific workflow. Treat those changes as a separate recovery item from restoring the workflow revision itself, and record which property effects need attention.

Follow a short release sequence

  1. Describe the old and proposed behaviour, including the intended treatment of records already eligible or waiting.
  2. Identify dependent assets and connected destinations.
  3. Write expected outcomes for an eligible record, an excluded record and each materially changed path. Add missing data or repeat events where relevant.
  4. Compare the proposed configuration with those outcomes. Assign an owner to check any action that must be observed in a destination system.
  5. Record the effective time, early observations, defects and any corrective release. Append corrections rather than overwriting the original release note.

HubSpot’s Test feature can help check whether a record will enrol and simulate its path through the current workflow. For troubleshooting, HubSpot recommends reviewing workflow details and checking the exact version the record may have been enrolled into. Preserve the version, effective time and relevant outcomes in your release record for longer-term investigation.

HubSpot has a limit of 100,000 successful workflow execution logs per day, calculated from midnight in the account’s time zone. Once that limit is exceeded, success and information logs are not stored for the rest of that day, although error logs continue to appear and records continue through the workflow.

Action logs appear in reverse chronological order, and their timestamps use the account’s default time zone. In larger workflows, enrolments and action activity can take time to appear, so note the time zone used in your release record and allow for that delay when reconciling a recent change.

HubSpot workflow data retention limits

  • 90daysAction logs retained
  • 6monthsEnrolment history retained

Prepare for recovery

Keep a recoverable reference before a consequential edit. HubSpot permits users with Super Admin or Workflows permissions to view and revert a workflow revision.

If the workflow is on, a reverted version can begin executing automatically. To prevent an immediate restart, turn off the workflow first, revert to the desired revision, then turn it on again.

A revision containing a webhook or custom code action cannot be reverted through that control; its read-only view can guide a manual repair. Restoring configuration cannot retract messages or updates already made. Identify affected records, completed and uncertain actions, and work still scheduled before deciding how to recover them.

In this guide

  1. Naming automations so a new operator can find themUse stable IDs, searchable names and useful descriptions to help new operators identify the right live automation.
  2. Copying a live workflow into a test environmentInventory dependencies, isolate outbound actions and check what a copied workflow can prove before updating production.
  3. Recording changes to trigger conditionsDocument the old and new entry rules, timing, repeat behaviour and expected audience difference for a workflow trigger edit.
  4. Rolling back an automation after a faulty updateContain a faulty workflow update, restore the right configuration and account for records affected before restarting.

More from Automation Builds