Workflows and Automation Builder

The workflow builder is the automation engine at the center of the platform. A workflow is a trigger, an optional set of conditions, and an ordered series of actions. Something happens, the workflow starts for that contact, and it walks that contact through the steps you laid out, waiting, branching and acting as it goes.

Almost every other module reaches into this one. Forms trigger workflows. Calendars trigger workflows. Pipeline stage changes trigger workflows. Inbound messages, call outcomes, payments, review submissions and tags all trigger workflows. And in the other direction, workflows send the emails, send the texts, move the pipeline cards, create the tasks, assign the owners and call the AI steps. If the build does anything without a human clicking, a workflow is doing it.

The mental model that matters most is that a workflow runs per contact, not once. Each contact who enters is walking their own copy of the path, holding their own position, their own wait timers and their own variable values. Operators who think of a workflow as a batch process get surprised by re-entry, by contacts sitting in waits for weeks, and by a change to a live workflow affecting hundreds of people mid-journey. Design it as a path one person walks, and the rest follows.

Triggers

• Form and survey submission, chat widget conversation started
• Appointment booked, rescheduled, canceled, status changed, reminder due
• Tag added or removed, contact created, custom field changed
• Pipeline stage changed, opportunity created, value changed
• Inbound message received, outbound message replied to, call status or outcome
• Payment or invoice events, review submitted, membership or course activity
• Date-based triggers such as birthdays, renewal dates and custom date fields
• Inbound webhooks from outside systems

Conditions and branching

• If and else branches on field values, tags, source, owner, pipeline position, appointment status
• Multi-branch splits for routing by category, location or product
• Percentage splits for testing two paths against each other
• Goal or exit conditions that pull a contact out when something happens

Actions

• Send email, SMS, voicemail drop, internal notification
• Place an outbound call or hand the conversation to an AI agent
• Add or remove tags, set custom field values, change the contact owner
• Create, move or update an opportunity; create and assign a task; add a note
• AI steps for classification, extraction, summarization and drafting
• Outbound webhook or integration call to an external system

Timing and flow control

• Wait for a duration, until a specific time of day, or until a condition becomes true
• Business-hours windows so nothing sends at three in the morning
• Re-entry settings controlling whether a contact can run through more than once
• Concurrency and volume guards, and the ability to pause a workflow without deleting it

Oversight

• Per-contact execution history showing which steps ran and what each returned
• Counts of contacts currently inside the workflow and where they are sitting
• Draft and published states so edits can be staged

1. Write the journey on paper first, as sentences: when this happens, do this, unless that, then wait, then this. If you cannot write it, you cannot build it.
2. Pick the narrowest trigger that captures the event. A broad trigger plus a condition is usually clearer and safer than a clever composite trigger.
3. Name the workflow so another operator knows what it does and when it fires, including the trigger in the name.
4. Add the entry conditions immediately, before any action. Filtering at the start is how you avoid texting the wrong people.
5. Set the re-entry rule deliberately. Decide whether a contact may run again, and if so after how long. This is the setting that causes duplicate-message incidents.
6. Build the happy path end to end with no waits, and test it with a single test contact so you can see the whole sequence in one pass.
7. Add the real waits, then add the business-hours window to every send step that a human will read.
8. Add the branches. Give every branch a real destination; a branch that ends with nothing is a contact silently abandoned.
9. Add the goal or exit conditions so that someone who books, buys or replies stops receiving the chase sequence immediately.
10. Add the internal steps: owner assignment, task creation, notification, pipeline movement, note logging. The build is not finished when the contact is messaged; it is finished when the team knows.
11. Verify every merge field and link in every message against a real test contact, including the empty-field case.
12. Test the unhappy paths explicitly: no reply, opted out, missing field, duplicate submission, contact already in the workflow.
13. Publish to a narrow audience or with a low-volume condition, watch the execution logs for the first batch, and read what actually ran rather than assuming.
14. Document the workflow for the client and for the next operator: trigger, purpose, exits, and what to check when it misbehaves.
15. Set a review date. Workflows rot as the business changes, and an unreviewed one is quietly sending last year's offer.

Workflows are the spine. Forms, Calendars, Pipelines, Campaigns, Payments, Reviews, Memberships and both AI agents all either trigger workflows or are driven by them. Almost nothing in a real build works without at least one.

Lead capture to booked appointment

A form submission triggers a workflow that tags the source, creates an opportunity at a new-lead stage, assigns an owner, sends an immediate SMS and email, waits, chases twice if there is no reply, and exits the moment the contact books. The booking triggers a second workflow for confirmation and reminders. Two workflows, one coherent journey.

No-show recovery

An appointment marked no-show triggers a workflow that moves the opportunity back, texts the contact a rebooking link, waits a day, chases once, and if nothing happens creates a task for the front desk to call. The pipeline stays honest without anyone updating it by hand.

Reactivation with AI triage

A scheduled workflow sends an offer to a dormant segment. A second workflow triggered by inbound reply runs an AI classification step, honors opt-outs immediately, routes the interested to a rep's task list and returns the rest to nurture with a future date. The human only touches real conversations.

• Re-entry is the number one incident cause. A contact who submits a form twice, or whose tag is re-applied, can enter twice and receive everything twice. Set the re-entry rule on every workflow you build.
• Editing a live workflow affects contacts already inside it. People sitting in a wait will continue into your new steps, sometimes out of order. For significant changes, build a new version and migrate rather than editing in place.
• Waits are long and real. A seven-day wait means a contact is in the workflow for seven days. Pausing or deleting the workflow strands them, and nothing tells you.
• Missing exit conditions produce the worst customer experience in the platform. Chasing someone who already booked, or already paid, is the most common complaint clients raise.
• Workflow loops are possible. A workflow that applies a tag which triggers a workflow that applies the first tag will run until something stops it. Check your trigger and action pairs for cycles.
• Branch dead ends. An unhandled condition means the contact quietly stops. Always give the else branch somewhere to go, even if that is a task for a human.
• Empty merge fields. A message addressed to a blank first name is the clearest possible signal that it was automated. Set fallbacks.
• Timezones apply to the contact, the account and the calendar separately. Business-hours windows and date triggers will behave unexpectedly if these disagree.
• Opt-out and consent are not automatic. A workflow will happily send to someone who should not be messaged. Honor opt-outs in the entry conditions, not only in the send step.
• Volume and rate limits bite at scale. A workflow triggered by a bulk import or a large list can attempt thousands of sends at once. Stage the import and condition the workflow.
• Nobody reads the logs until something breaks. Execution history is the only honest account of what happened. Make reading it part of go-live, not of incident response.
• Cloned workflows carry the old client's assets. Duplicating a build copies references to calendars, pipelines, numbers and templates that may not exist or may belong elsewhere. Re-check every step after a clone.