Workflows

Workflows are the place to set up the parts of your CS motion that need to be precise and predictable. They use a standard trigger / condition / action shape.

Triggers

Choose whether the workflow targets companies or contacts. In Enrollment trigger, choose Trigger when and configure the event or schedule:

• Start manually from a selection of companies or contacts.
• Run when a compatible signal fires.
• Use a supported event directly, such as criteria matching, a topic mention, a product event, a meeting, or an audience change.
• Run on a configured schedule.

The editor offers triggers compatible with the target and enabled features. A health or CRM-field condition can be expressed through criteria; a topic trigger can react to a configured topic mention.

Conditions

Conditions narrow when the action should actually run. For example:

• Health changed to At risk and the customer has not been contacted in the last 30 days.
• A competitor mention and the customer is on an annual contract.

Exit conditions

Configure Exit conditions when a target should leave early, for example after booking the meeting the workflow was trying to secure. Matching any one exit condition ends that target's run. Some enrollment triggers also offer an exit when their original condition stops matching.

With no exit condition, the workflow runs until its steps complete or it is otherwise stopped.

Publish and enroll existing matches

Save your draft and choose Publish when its trigger, steps, and approvals are ready. For supported criteria and audience triggers, the publish dialog can offer to enroll matching companies or contacts that have never been enrolled before. Review the count and opt in only when you intend to process that existing group.

This is separate from future trigger events. Changing a definition does not imply that every existing matching record will be enrolled. Very large existing groups can exceed the dialog's enrollment limit; publishing the workflow remains available.

Change a live workflow

Saving a draft leaves the published workflow unchanged. Choosing Publish replaces its live definition, including the steps and connections used by accounts already running through it.

Before publishing an edit:

1. Open the affected steps' pipeline views and inspect their active runs.
2. Check the next step for those accounts against the proposed change. Existing runs will follow the new connections when they advance.
3. Keep any step that an active run still needs. Deleting a pending step can cause that run to fail when Cust tries to execute it.
4. Publish, then return to the affected runs to check their progress and outcomes.

For example, Pfizer and Siemens are both waiting in a renewal-review step. You change its next step from Create CSM task to Send email and publish. When those existing runs finish their review step, they follow the new email path. The change applies to future enrollments as well.

Use a separate workflow for a new cohort

To introduce a new sequence while current accounts finish the old one, open the workflow's menu and choose Duplicate workflow. The copy starts as a separate, paused draft. Rename it, configure its enrollment criteria or manual target selection for the new cohort, and publish when ready.

Keep the original workflow in place for its active runs. Pause workflow stops its new enrollments while existing runs continue. Check the original and copied enrollment criteria together so the same account does not enter both sequences unintentionally. Pausing the original does not isolate its active runs from a later edit to that original workflow.

Actions

Actions are what the workflow does when the trigger fires and the conditions hold. A workflow can chain several action steps in order. Common actions:

• Create an action item for the CSM in Action Hub.
• Send an automated email on behalf of the CSM (with optional CSM approval).
• Run an email sequence (see below).
• Update a CRM attribute.
• Run a piece of account research and save the result as a custom attribute on the account.
• Push a value back to an external system through a custom script.

The pipeline view

Each step in a workflow has its own pipeline view: a Kanban board where every card is one account running through that step. The columns are the step's possible outcomes, for example Queued, Running, Sent, Replied, and Failed for an email step. You can see at a glance how many accounts reached each outcome, and search within a stage by company or contact.

This is different from Projects and Guidance, where one account moves through the stages of a single process. A workflow step's pipeline shows many accounts moving through one step, so it answers "what happened when this step ran" rather than "where is this account in the process".

The editor canvas carries the same signal at a glance: each step shows small counters for runs that are in progress, succeeded, and failed. Click a counter to jump to that step's runs, already filtered to the matching status.

Step objectives

Running a step is not the same as it working. Objectives let you define what success means for a step and measure how often it is reached.

An objective is a named condition on the step's target (the company or the contact), built with the same query builder as filters: "booked a meeting", "usage back above the threshold", "replied within a week". Each objective has an attribution window, the number of days after the step runs within which the condition must become true to count.

The pipeline view then reports performance as KPI cards: how many targets were enrolled, and for each objective, what share reached it. Click an objective card to filter the pipeline to just the runs behind that number. A step that was renamed or republished keeps its history. Its metrics can therefore include runs from before and after an edit; use a separate workflow when you need a separate cohort and history.

Email sequences

An email sequence step sends a series of emails on a schedule until the customer replies. After the final email, you can optionally wait for a reply for a set number of days before the sequence finishes. If a reply lands inside that window the sequence stops there; if it does not, the sequence completes with a no-reply outcome so a later step or workflow can take over.

Sequences handle the replies they get along the way. An out-of-office auto-reply does not count as a real answer: Cust detects it and postpones the next send instead of continuing the schedule into an empty inbox. If a sequence was interrupted (for example by a disconnected mailbox), you can resume it from where it stopped.

Sequence emails can personalize with variables, including the account's metric values and the date the company was created, alongside the usual contact and company fields.

A sequence step gives you control over volume and safety:

• Multiple contacts per company: a sequence can enroll several matching contacts on the same account, and each contact is tracked separately.
• Daily send limit: a per-day ceiling (between 50 and 200, 200 by default) on how many emails the step sends from one account, so a big trigger cannot flood your outbox.
• Frequency cap: skip re-enrollment when the same target was already enrolled within the last X days.
• Approvals with a due date: when a sequence requires CSM approval before sending, you can set how many days the approval task has before it is due, so drafts do not sit unreviewed.

Example workflows

A few patterns customers use most:

• No-contact-in-30-days rescue: when health changes to At risk and there has been no contact for 30 days, queue an action item to reach out, with a draft email pre-written.
• Renewal kickoff: 120 days before the renewal date, enroll the customer into the renewal Guidance and create the first action item.
• Account research on key event: when a customer mentions an acquisition or funding round, kick off a research workflow that pulls news and saves a summary as an attribute on the account.

Workflows give you the deterministic side of the system. For the cases where you want AI judgement instead of fixed rules, lean on Guidance.

Set up a workflow

Recover a failed run

Open the run and inspect its failed step and any actions that already completed. Fix the underlying problem, then retry the individual failed step or choose Retry all failed steps. Check the eventual result: a queued retry is not yet a successful run, and retrying does not roll back completed external actions.

Stop all branches when a step fails defaults to on in advanced settings. When it is off, other branches can continue while a step remains failed.

Pause, abort, or archive