Skip to main content
An enrollment is one lead’s run through one workflow. It starts the moment the lead enters and ends when the run reaches the end of the flow, is stopped by a block, fails, or is cancelled. A lead can be in more than one workflow at the same time, and each of those runs is a separate enrollment.
Where
Leads→Prospects
Your role needs
Read access to Prospects read-leads. Admin, Member and Viewer have it by default.
To create or change
create-leads to add one, update-leads to change one, on top of the permission above.
If you cannot find this in your sidebar, your workspace may have a custom menu configuration. Contact support and we will check it for you.
On a lead’s own page, every enrollment that lead has, past and present, lives on the Automations card. This page covers what that card and its journey view actually show.

​
How it behaves

​
Two statuses mean the run is still moving; four mean it is over

The card reads this split directly: every Active or Waiting enrollment is listed first, and the most recent one is already expanded. The four finished states move under a collapsed history count. The card asks for the 50 most recent enrollments for that lead and shows nothing older. Cancel a running enrollment and it moves straight from the live list into the history, marked Cancelled. Deactivating or deleting a workflow stops new leads entering it. It does not touch the runs already inside: they keep going against the graph they started on, so a workflow you switched off can still send tomorrow. Cancel each run you want stopped, one at a time.

​
Completed does not mean it worked

Completed is a catch-all, not a success badge. It covers the ordinary ending, where the last block ran and there was nothing after it, and the two finish blocks, Goal Reached and Mark Converted. It also covers a send block that ran out of options and gave up:
  • No email account in the workspace is active, so the block ends the run rather than waiting for one that will never exist.
  • Accounts exist, but none became free inside the block’s retry window.
  • The retries were spent on rest days, or on the lead’s holiday.
  • A channel send was over the account’s message budget, or never fell inside its sending window, for the whole of its retry window.
Nothing on the card or in the journey tells you which of those happened. The reason is recorded on the run and never shown: the step reads Done and the closing marker says the run reached the end. So a lead sitting at Completed with no message against it is a reason to check your email accounts, not evidence that the flow ran.

​
Waiting is not stuck

Waiting covers three ordinary reasons a run suspends on its own: a timed block, a sending window, or an event it is watching for, most often the lead replying. All three resolve without you doing anything. If the run knows exactly when it picks back up, the journey says so; if it does not, it just says it is Waiting for the lead to respond. There is a fourth reason, and it is the one the card does not spell out: a lead whose own automation is switched off. Its runs still read Waiting, but they park. The engine comes back on a timer, finds automation still off and parks the run again. Any resume time on the row is not a promise that anything happens then. Switch the lead’s automation back on and the run picks up from the block it stopped at. One narrow exception: a workflow triggered by the very act that paused the lead, such as a booked meeting, is allowed to run anyway.

​
The rail reads past, now and next

Expand a row and the journey lays the run out top to bottom: every step already run, oldest first, then the one it is on, then what is reachable from there.
  • A past step reads Done if it moved straight through, or Took “” if it picked a branch, naming the branch it took. Skipped and Failed show up here too, and a failed step carries its error underneath. A Failed step does not always sink the run: a step that can be retried is retried in place, and each attempt leaves its own row.
  • The current step is the one emphasized marker on the rail. If the run is moving it says Runs next; if it is suspended, its caption is the resume time or the wait-on-the-lead line described above.
  • What comes after is drawn dashed, because it has not happened: Then for a single path, or Next if “” for each option a branching block could take.
A run suspended mid-flow shows its wait block twice on purpose: once in the past list marked Paused here, the moment it suspended, and again as the current step with its resume caption. It is the same block described two ways, not a repeat. A finished run has no current step and nothing dashed. Its rail is the steps it ran, then an End of the run marker whose caption says how it ended: reached the end, left the workflow, stopped by an error, or cancelled. A finished run that recorded no steps at all says that instead of drawing a rail. Everything on the rail, a step’s name included, is read against the graph snapshot pinned to that run, not whatever the workflow’s canvas looks like today. Edit the workflow later and an in-flight run keeps describing the version it is actually executing. If whoever built it gave a block its own name, the rail uses that name; otherwise it falls back to the block type’s own label.

​
Enrolling a lead by hand

Enroll in the card header opens a picker of workflows this lead can be dropped into directly, and it is narrower than every workflow you have. Only Active workflows carrying a Manual / Test trigger block qualify, and a workflow this lead is already running is left off the list too. A workspace that has not built one, or has only put a manual trigger on a draft, gets a dialog saying there are no active workflows with a manual trigger to enroll into. Pick a workflow and the lead enrolls straight away, with a confirmation toast. It can also fail into a generic error that does not say why. Three causes are worth knowing:
  • The lead’s own automation is switched off. A paused lead is refused outright.
  • The lead has already been enrolled into that workflow through that same manual trigger before. By default a lead may enter through a given trigger block once and never again, whether or not that first run finished.
  • Your role has no update access to workflows, which is the case for a Viewer. The button is still there; it just fails.

​
Cancelling a run

Cancel sits on every enrollment that is not already over. It stops that one run immediately, moves it into the history as Cancelled, and cannot be undone: the confirmation dialog says so, and Cancel enrollment is the button that commits it. It touches nothing else, so any other workflow the same lead is running keeps going exactly as it was.
Neither Enroll nor Cancel is hidden behind a permission check in the interface, so anyone who can open the lead sees both. The server checks anyway: both need update access to workflows, which Admin and Member have and Viewer does not. Opening a journey needs read access to workflows on top of read access to the lead, and without it the rail says it could not load the run’s steps instead of showing them.

​
The card follows the Workflows switch

The Automations card and the Workflows entry in the sidebar are behind the same switch. If Workflows is not in your menu, the card is not on your leads either, and there is no workspace setting that turns it on.

​
Limits

Workflow stats

The same six statuses, aggregated: a step funnel, conversion and average time for a whole workflow.

How a workflow's sends are scheduled

What actually decides when a waiting send block goes out.

Workflow troubleshooting

A block that is missing, a workflow that will not activate, a lead that has not moved.

The lead details page

Every other card on a lead’s page, and what each one depends on.