Review the Dependency Map Before Changing an Email Automation

Before changing an email automation, export a typed dependency graph and review every upstream trigger, downstream action, shared object, active contact, and rollback edge. The visible canvas is evidence about the selected workflow, not proof of the whole blast radius.

Editorial disclosure: Prepared by Marketing Wiki Research Automation under standing direct-publication authorization and not independently reviewed. Product capabilities are vendor-documented unless labeled otherwise; sources were refreshed on September 4, 2026.

ActiveCampaign’s Automations Map guide describes links created by actions and triggers, active and inactive state, filters, and statistics for contacts and campaigns. It also says that when an account has more than 100 automations, the map displays only connected automations. A useful map can therefore be intentionally incomplete for inventory purposes.

Build a typed graph#

Represent nodes and edges explicitly:

Scroll table →

Node type	Examples
Entry	form, list add, event, inbound email, schedule
Automation	welcome, trial nurture, renewal, win-back
Message	email template, campaign, SMS, in-app message
State	tag, field, list, score, subscription status
External action	webhook, CRM update, ad audience, support task
Stop/control	goal, exit, frequency cap, suppression, manual review

Edge types should include starts, stops, writes, reads, sends, waits-for, excludes, and reports-to. Direction matters. “Connected” is not sufficient for deciding what breaks.

Reconcile the map with inventories#

Export or list every automation, including inactive and archived objects. Then compare the graph’s node count with the platform inventory. For any discrepancy, identify whether the object is isolated, hidden by a threshold, inaccessible to the current role, or excluded by the map’s definition.

Do the same for templates, campaigns, lists, fields, tags, webhooks, goals, and credentials. Search external repositories and automation tools for object IDs. A webhook consumer cannot appear on a platform canvas if it lives elsewhere.

Migma’s campaign overview and webhook documentation illustrate separate surfaces that an operating graph may need to connect: campaign state, messages, audience, delivery, and external events. Record those boundaries even when one vendor does not visualize them together.

Calculate blast radius#

For the selected node, record:

upstream = all paths that can enter or alter this automation
downstream = all paths this automation can start, stop, write, or send
shared_state = objects read or written by this and another workflow
in_flight = contacts currently waiting or executing
external = calls or data consumers outside the platform

Set a maximum traversal depth only for display. The audit should continue until a boundary is deliberately classified.

Use this worksheet:

Scroll table →

Dependency	Current behavior	Proposed behavior	In-flight treatment	Owner	Rollback
entry event	exact schema/version	changed condition	old events drain or re-evaluate	data owner	restore rule version
shared tag	written by two flows	rename/remove	preserve old readers	lifecycle owner	dual-write period
email	template/version	replacement artifact	contacts keep pinned version or migrate	editor	restore template ID
webhook	endpoint and retry policy	new consumer	queued attempts reconciled	engineering	route to old endpoint

Test boundaries, not only the happy path#

Freeze fixtures for:

one contact qualifying through two upstream paths;
an inactive automation that another flow still attempts to start;
a contact already waiting when delay or message changes;
an exit condition becoming true during the wait;
a shared tag renamed while another workflow reads it;
a webhook delivered twice or out of order;
suppression arriving after entry but before send;
rollback after some contacts moved to the new version;
an automation absent from the visible map;
a credential or external endpoint revoked during execution.

Assert final contact state and side-effect count. A test that merely reaches the end of a workflow can miss a duplicate email or stale field.

Choose an in-flight policy#

Every change needs one of three policies:

Pin: existing contacts finish the old immutable version; new entrants use the new version.
Migrate: eligible in-flight contacts move under an explicit state mapping.
Drain: stop new entries, let old work finish, then activate replacement.

Do not let the platform’s default decide silently. Record version IDs, cutover time, entry freeze, and how delayed steps behave across the boundary.

Release and rollback#

Before activation, capture the graph, inventory reconciliation, object versions, active-contact counts, boundary-test results, suppression behavior, and owner approval. Start with a canary population or shadow evaluation where the platform supports it.

Monitor entries, exits, sends, skips, duplicates, goal completions, webhook failures, and contacts stuck in waits. Rollback must restore rules and shared state while preventing a second send. If external state changed, compensation may be safer than replay.

Evidence limits#

Marketing Wiki did not inspect a live map or automation. ActiveCampaign documents the current visualization and its display boundary; Migma documents adjacent campaign and event surfaces. The typed graph and release method are portable controls, not evidence that a platform map is complete or that a particular change is safe.