> ## Documentation Index
> Fetch the complete documentation index at: https://help.pipelime.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Enrollments and the lead journey

> Follow one lead through a workflow: where it is now, which branch it took and why it stopped.

export const Screenshot = ({id, alt, caption, frame = 'browser', url, marks = [], lang = 'en', workspace = 'northwind-outbound'}) => {
  const src = `/images/screenshots/${lang}/${id}.png`;
  const chrome = url ? `app.pipelime.ai/${workspace}${url}` : 'app.pipelime.ai';
  return <figure className={`pl-shot pl-shot--${frame} not-prose`}>
      <div className="pl-shot__frame">
        {frame !== 'bare' && <div className="pl-shot__bar">
            <span className="pl-shot__dots">
              <span className="pl-shot__dot" />
              <span className="pl-shot__dot" />
              <span className="pl-shot__dot" />
            </span>
            <span className="pl-shot__url">{chrome}</span>
          </div>}
        <div className="pl-shot__media">
          <img src={src} alt={alt} loading="lazy" />
          {marks.map(mark => <span key={mark.n} className="pl-shot__mark" style={{
    left: `${mark.x}%`,
    top: `${mark.y}%`
  }} aria-hidden="true">
              {mark.n}
            </span>)}
        </div>
      </div>
      {caption && <figcaption className="pl-shot__caption">{caption}</figcaption>}
    </figure>;
};

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.

<div className="pl-availability">
  <div className="pl-availability__row">
    <div className="pl-availability__label">Where</div>
    <div className="pl-availability__value"><span className="pl-path">Leads<span className="pl-path__sep">→</span>Prospects</span></div>
  </div>

  <div className="pl-availability__row">
    <div className="pl-availability__label">Your role needs</div>
    <div className="pl-availability__value">Read access to Prospects <code>read-leads</code>. Admin, Member and Viewer have it by default.</div>
  </div>

  <div className="pl-availability__row">
    <div className="pl-availability__label">To create or change</div>
    <div className="pl-availability__value"><code>create-leads</code> to add one, <code>update-leads</code> to change one, on top of the permission above.</div>
  </div>

  <div className="pl-availability__note">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.</div>
</div>

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.

<Screenshot id="workflows/enrollments-and-lead-journey--card" url="/leads/prospects/482" alt="The Automations card on a lead's page: one workflow row with an Active status pill, expanded to show the current step and how long ago the lead enrolled" caption="The most recently started live run opens on its own. A lead running more than one workflow lists one row per enrollment." />

## How it behaves

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

| Status        | Still moving? | What it means                                                                 |
| ------------- | ------------- | ----------------------------------------------------------------------------- |
| **Active**    | Yes           | Runnable now, picked up the next time the engine passes over it               |
| **Waiting**   | Yes           | Suspended, and set to resume on its own                                       |
| **Completed** | No            | Stopped for any reason that is not an exit block, a failure or a cancellation |
| **Exited**    | No            | A **Stop / Exit** block ended it early                                        |
| **Failed**    | No            | A step failed for good, or a runtime guard stopped the run                    |
| **Cancelled** | No            | Stopped by hand, from the **Cancel** control on this card                     |

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**.

<Screenshot id="workflows/enrollments-and-lead-journey--journey" url="/leads/prospects/511" alt="The Automations card's journey rail on a Waiting enrollment: the current step captioned with when it resumes, and the next step dashed in below it" caption="Nothing here is stuck. The caption on the current step names when this run picks back up." />

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 “{handle}”** 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 “{handle}”** 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.

<Screenshot id="workflows/enrollments-and-lead-journey--enroll-dialog" url="/leads/prospects/482" alt="The manual enrollment dialog in its empty state: a message saying there are no active workflows with a manual trigger to enroll into" caption="The common case. Only a workflow with its own Manual / Test trigger block ever appears here." />

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.

<Note>
  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.
</Note>

### 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

|                                |                                                                                                              |
| ------------------------------ | ------------------------------------------------------------------------------------------------------------ |
| Where it lives                 | The **Automations** card on a lead's own page                                                                |
| Enrollments shown per lead     | Up to the 50 most recent, newest first                                                                       |
| Auto-expanded on load          | The newest still-moving enrollment only; the history stays collapsed                                         |
| Manual enrollment offered      | Active workflows with a **Manual / Test** trigger, excluding ones already running for this lead              |
| Manual enrollment repeated     | Not by default: one enrollment per lead per trigger block, ever                                              |
| Cancelling                     | Only on a still-moving enrollment; instant, and cannot be undone                                             |
| What cancelling affects        | Just that one enrollment; every other workflow the lead is running is untouched                              |
| Journey source                 | The run's own pinned graph snapshot, never the workflow's current canvas                                     |
| Permission to enroll or cancel | Update access to workflows, checked server-side even though the buttons show to anyone who can open the lead |

## Related

<CardGroup cols={2}>
  <Card title="Workflow stats" icon="chart-line" href="/en/workflows/workflow-stats">
    The same six statuses, aggregated: a step funnel, conversion and average time for a whole workflow.
  </Card>

  <Card title="How a workflow's sends are scheduled" icon="clock" href="/en/workflows/how-sends-are-scheduled">
    What actually decides when a waiting send block goes out.
  </Card>

  <Card title="Workflow troubleshooting" icon="wrench" href="/en/workflows/troubleshooting">
    A block that is missing, a workflow that will not activate, a lead that has not moved.
  </Card>

  <Card title="The lead details page" icon="id-card" href="/en/leads/lead-details-page">
    Every other card on a lead's page, and what each one depends on.
  </Card>
</CardGroup>