Design triggers, conditions, campaigns, onboarding, notifications, integrations, measurement, governance, and repair.
Automation can move observable customer states through repeatable actions such as tagging, campaign enrollment, notifications, and access. It should not make high-consequence decisions from ambiguous data or hide a broken manual process.
Leave with bounded workflows, owners, logs, and manual fallbacks.
Read the starting guide →Start with the question that can change your decision. Each summary below gives the current bottom line and opens a complete guide with evidence, limits, and practical next steps.
Automation can move observable customer states through repeatable actions such as tagging, campaign enrollment, notifications, and access. It should not make high-consequence decisions from ambiguous data or hide a broken manual process.
Work through this decision →Use the smallest construct that represents the logic clearly and can be tested, monitored, and repaired. A simple trigger-action rule may be safer than a sprawling workflow when branches and timing add no business value.
Work through this decision →Begin with an observable entry state and explicit exclusions, then add bounded branches, waits, actions, goals, and exit conditions. Test the path with controlled contacts and preserve a version record.
Work through this decision →A good trigger is specific, observable, and stable: a form submission, purchase, tag, campaign action, booking, or date. Avoid triggers based on assumptions the system cannot verify.
Work through this decision →If you are beginning from scratch, this sequence moves from overall fit to the details most likely to alter cost, risk, or implementation. If you already know the basics, jump directly to the guide that resolves your remaining uncertainty.
Automation can move observable customer states through repeatable actions such as tagging, campaign enrollment, notifications, and access. It should not make high-consequence decisions from ambiguous data or hide a broken manual process. Use current primary documentation, explicit assumptions, one representative customer journey, and a recoverable operating plan.
Use the smallest construct that represents the logic clearly and can be tested, monitored, and repaired. A simple trigger-action rule may be safer than a sprawling workflow when branches and timing add no business value. Use current primary documentation, explicit assumptions, one representative customer journey, and a recoverable operating plan.
Begin with an observable entry state and explicit exclusions, then add bounded branches, waits, actions, goals, and exit conditions. Test the path with controlled contacts and preserve a version record. Use current primary documentation, explicit assumptions, one representative customer journey, and a recoverable operating plan.
These pages are deliberately separated when they answer different buyer questions. Related links reconnect the parts without forcing you through a fixed reading order.
Automation can move observable customer states through repeatable actions such as tagging, campaign enrollment, notifications, and access. It should not make high-consequence decisions from ambiguous data or hide a broken manual process. Use current primary documentation, explicit assumptions, one representative customer journey, and a recoverable operating plan.
Read the guide →Practical guideUse the smallest construct that represents the logic clearly and can be tested, monitored, and repaired. A simple trigger-action rule may be safer than a sprawling workflow when branches and timing add no business value. Use current primary documentation, explicit assumptions, one representative customer journey, and a recoverable operating plan.
Read the guide →Practical guideBegin with an observable entry state and explicit exclusions, then add bounded branches, waits, actions, goals, and exit conditions. Test the path with controlled contacts and preserve a version record. Use current primary documentation, explicit assumptions, one representative customer journey, and a recoverable operating plan.
Read the guide →Practical guideA good trigger is specific, observable, and stable: a form submission, purchase, tag, campaign action, booking, or date. Avoid triggers based on assumptions the system cannot verify. Use current primary documentation, explicit assumptions, one representative customer journey, and a recoverable operating plan.
Read the guide →Important limitationsConditions should depend on documented fields or events, handle missing values, and avoid sensitive inference. Every branch needs an owner, expected population, and test record. Use current primary documentation, explicit assumptions, one representative customer journey, and a recoverable operating plan.
Read the guide →Practical guideDelay length should follow the promised cadence, time needed to act, business hours, expiry, and message relevance. Verify time-zone behavior and what happens when eligibility changes during the wait. Use current primary documentation, explicit assumptions, one representative customer journey, and a recoverable operating plan.
Read the guide →Practical guideA nurture sequence should help the subscriber understand the problem, alternatives, mechanism, fit, and next step. Exclude buyers and people who already completed the goal, and stop when continued messages are no longer relevant. Use current primary documentation, explicit assumptions, one representative customer journey, and a recoverable operating plan.
Read the guide →Practical guideAutomate confirmations, access, preparation, reminders, and progress cues, but keep a support route and owner for exceptions. The customer should always know what happened, what is next, and where to get help. Use current primary documentation, explicit assumptions, one representative customer journey, and a recoverable operating plan.
Read the guide →Buying guideConfirm the person is eligible to receive follow-up, the purchase remains available, and the message helps resolve uncertainty. Exclude purchasers, refunded customers, invalid addresses, and requests to stop. Use current primary documentation, explicit assumptions, one representative customer journey, and a recoverable operating plan.
Read the guide →Practical guideDifferentiate registration, attendance, meaningful viewing, offer interest, purchase, and no-show only when the events are reliable. Send the most useful next resource rather than the most aggressive message. Use current primary documentation, explicit assumptions, one representative customer journey, and a recoverable operating plan.
Read the guide →Practical guideDerived segments should remain traceable to source events and fields. Preserve acquisition source, consent, purchase, product access, and lifecycle facts instead of replacing them with opaque labels. Use current primary documentation, explicit assumptions, one representative customer journey, and a recoverable operating plan.
Read the guide →Practical guideConfirm supported objects, fields, events, directions, delay, history, duplicate behavior, errors, and recovery. An integration can be official and still omit the business-critical state. Use current primary documentation, explicit assumptions, one representative customer journey, and a recoverable operating plan.
Read the guide →Practical guideDefine one decision or handoff, endpoint, schema, authentication, schedule, quota, retry, idempotency, monitoring, privacy boundary, and fallback. Avoid turning a simple workflow into custom infrastructure without a clear return. Use current primary documentation, explicit assumptions, one representative customer journey, and a recoverable operating plan.
Read the guide →Practical guideReview acquisition, contact quality, delivery, sales, access, support, refunds, workflow failures, and the next improvement in one consistent meeting or checklist. Separate observation, interpretation, action, and verification. Use current primary documentation, explicit assumptions, one representative customer journey, and a recoverable operating plan.
Read the guide →Practical guideDelivery, clicks, replies, conversions, unsubscribes, complaints, and downstream value answer different questions. Review cohorts and message purpose, while treating privacy-affected open data cautiously. Use current primary documentation, explicit assumptions, one representative customer journey, and a recoverable operating plan.
Read the guide →Practical guideConfirm event definitions and source consistency, then locate the largest consequential drop. Pair counts with recordings, support questions, surveys, or controlled tests before attributing cause. Use current primary documentation, explicit assumptions, one representative customer journey, and a recoverable operating plan.
Read the guide →Important limitationsEvery active workflow needs an owner, purpose, version, dependencies, test records, protected fields, monitoring, manual fallback, and retirement condition. Review after offer, integration, policy, team, or platform changes. Use current primary documentation, explicit assumptions, one representative customer journey, and a recoverable operating plan.
Read the guide →Practical guideCapture the contact, trigger, time, fields, tags, workflow version, branch, wait, action, send or access status, and recent changes. Reproduce with one safe record and edit the smallest failing step. Use current primary documentation, explicit assumptions, one representative customer journey, and a recoverable operating plan.
Read the guide →