Workflow Lifecycle and Statuses

Workflow Lifecycle Overview

A workflow begins in Draft status while you configure its steps. When you're ready to use the workflow, you activate and publish it. Publishing creates a precise, versioned snapshot of your workflow. At any time, there is one published version that represents the most up-to-date workflow logic.

As automation triggers occur, contacts are enrolled into the current published version. This approach allows you to make updates to workflows without disrupting any processes already underway for existing enrollments.

Workflow Statuses

Draft: The workflow is in authoring mode and not yet considered live. Steps, configuration, and structure may be freely added, removed, or reordered; publishing has either never occurred or the current edits differ from the last published version. No automatic enrollments should trigger on a Draft workflow and manual enrollments should typically be blocked. Use this state for iterative building and safe experimentation before exposing logic to production data flows.

Active: The workflow is live and eligible to receive new enrollments (based on its trigger type) and to advance existing executions through their steps. This status usually indicates there is at least one published version; changes made while Active (in the authoring surface) are not applied to executions until republished, so authoring edits create a divergence (unpublished changes).

Paused: The workflow has been temporarily halted: no further step progression should occur for in-flight executions and no new automatic enrollments should begin while paused. Existing executions remain persisted in a non-terminal state (often still referencing their current version and step indices) and may be resumed later without loss of context. Paused is intended for short-term maintenance, emergency intervention, or batch data corrections—distinct from Cancelled (permanent stop) and Archived (retired record).

Cancelled: The workflow has been permanently stopped prior to archival. All active/pending/paused executions are force-cancelled and will not resume; no new enrollments are allowed. Cancellation is a terminal administrative action signaling that the workflow’s logic should no longer run, often due to deprecation, replacement, or a critical flaw discovered in its design. Unlike Archived, Cancelled emphasizes an abrupt termination event rather than an orderly retirement after completion of its lifecycle.

Archived: The workflow is retired from active use and retained for historical reference, audits, or reporting. No new enrollments occur, and typically there should be no remaining active executions (all should be completed or previously cancelled). Archival is the final lifecycle stage after a workflow is no longer needed operationally but must remain accessible for review, metrics, or cloning as a template for future workflows. It is generally more intentional and orderly than Cancelled, implying successful end-of-life rather than emergency termination.

Workflow Execution

Workflows are background processes that are periodically evaluated or are directly triggered by a specific event.  In most cases, the background processes will re-evaluate workflow trigger conditions every 5-15 minute intervals depending on the type of workflow. Most auto-triggers are evaluated every 5 minutes, dynamic list removal triggers every 10 minutes, and P2P triggers every 15 minutes.  If you take action that is supposed to trigger a workflow, you may find the workflow not triggering immediately, and the reason is because of this built-in latency.

Workflow Revisions

Workflows aren’t static - they change as you refine them. To keep things stable and reliable, every time you publish a workflow, the system creates a snapshot (a frozen copy) of exactly how it looked at that moment. That way, the workflow you’re editing and the workflow that’s running stay separate.

Here’s why this matters:

1. Stability for Running Workflows

Once published, a workflow version never changes. Any automations already in progress continue to run against that frozen version, even if you make edits later.

2. Safe Editing & Previews

You can experiment freely—adding, removing, or reordering steps—without breaking what’s already running. Nothing changes for live workflows until you choose to publish.

3. Clear Change Tracking

If you’ve made updates since the last publish, the system will flag that there are unpublished changes, so you always know whether your edits are live or still in draft.

4. Built-In Audit Trail

Every published version is stored permanently. This is essential for debugging, compliance reviews, or simply understanding what exactly ran for a past automation.

5. Consistent Results

Re-running or reviewing an old workflow means you’ll see the exact same steps and settings as before. There’s no risk of hidden edits changing past results.

6. No Risky “Live Edits”

Instead of changing logic while it’s running, you always create a new version. That avoids messy halfway-changes and ensures smooth rollouts.

7. Multiple People Can Edit

Even if several team members are editing, only the published version goes live. Drafts can be messy, incomplete, or experimental - production workflows remain safe.

8. Room for Future Features

Because each version is its own snapshot, it’s easy to imagine future features like rolling back to an older version, comparing performance between versions, or running A/B tests.

9. Reliable Cancellations & Updates

Bulk cancellations or status changes always respect the version that was running at the time. Edits you’re working on now won’t affect past runs.

---

In short: workflow versioning separates design-time (where you experiment) from run-time (where stability matters). This gives you reliability, traceability, and confidence when publishing changes.

 

How the Workflow Engine Handles Failed Steps

When an action step in your workflow fails, the workflow engine automatically manages retries and failure states to ensure stability and visibility.  For action step "Apply a Filter", you can indicate what happens if the filter condition is not met (stop workflow, retry, continue).  However for cases where a step experiences an issue (for example: you setup an SMS step but your account no longer supports SMS), the step will result in an error.  Here’s what happens:

Retry Attempts and Logging

• Each time a step runs, the engine keeps track of the number of attempts.

• The first run starts with attempt 0.

• If the step fails, the attempt count increases (1, 2, 3, …) and the failure is logged.

Retry Schedule (Linear Backoff)

The engine retries failed steps with increasing wait times:

• First failure (attempt = 1): Retry is scheduled after 1 minute.

• Second failure (attempt = 2): Retry is scheduled after 2 minutes.

• Third failure (attempt = 3): The maximum retry limit is reached. The step is marked Failed. No further retries are attempted and the action step settings for how to handle failed status is activated. (see below for more on options).

This pattern is called linear backoff, because the delay increases in a predictable way (1 minute, then 2 minutes, etc.).

Step Status During Retries

• While waiting for a retry, the step status is shown as Pending.

• This is different from Waiting, which indicates a planned pause in the workflow.

• Pending status means the system is actively scheduling a retry attempt.

Summary:

• Up to 3 attempts per step (1 original + 2 retries).

• Linear backoff retry timing: +1 min, +2 min.

• Step marked Failed if retries are exhausted.

• Success after retries is logged as Resolved for transparency.

 

Successful Resolution After Retries

If a step succeeds after one or more retries:

• The outcome is logged as Resolved (instead of Completed).

• This distinction shows that the step required retry attempts before it succeeded, giving you visibility into reliability issues.

 

Failed Status after Retries

Each action step in a workflow can be configured with a Fail Action. This setting controls what happens after the system has exhausted all built-in retries and the step still fails.

For Condition steps, this will correspond to condition not being met.

Available Fail Action Options

1. Continue

• The failed step is recorded as Failed (for visibility).

• The workflow itself remains In Progress.

• The engine immediately moves on to the next step.

2. End Workflow

• The failed step is marked Failed.

• The workflow is marked as Completed (successfully ended).

• The workflow pointer is cleared, meaning no further steps will run.

3. Skip Remaining

• Behaves the same as End Workflow.

• The difference is mostly semantic: it’s intended to show that you want the workflow to end successfully after this failure.

4. Branch

• The failed step is marked Failed.

• The system tries to jump to another step in the workflow using the configured On Fail Go To Step ID.

• If the target step exists:

  • Execution continues from that step.

• If no match is found:

  • The engine simply moves forward to the next step in order.

5. Retry (Extended Mode)

• Adds an extra retry layer beyond the built-in retry attempts.

• You configure two values:

  • Max Retry Days (default: 30)

  • Retry Interval Days (default: 1)

• Behavior:

  • If the step has been failing longer than Max Retry Days, it acts like Continue (skips to next step).

  • Otherwise:

    • Step is reset to Pending.

    • Next attempt scheduled after Retry Interval Days.

    • Attempt counter is reset so the standard retry cycle starts fresh.

    • A distinct Retry Count is tracked.

    • A history log entry is added showing "retry".

6. Enroll Workflow

• The failed step is marked Failed.

• If a valid On Fail Enroll Workflow is provided:

  • A new workflow execution is created in the target workflow.

  • The current workflow is marked as Completed (successfully ended, even though the step failed).

Summary Table