Workflow uses one reusable goal definition in two different ways: a terminal **Goal step** inside the graph, or a top-level **Success goal** that watches subscriber events and state while the run is active.

## Choose the right goal

| Need                                      | Use              | Does the run complete?                   |
| ----------------------------------------- | ---------------- | ---------------------------------------- |
| The graph path itself proves success      | Goal step        | Always                                   |
| An external event proves conversion       | Success goal     | Only when `Complete workflow` is enabled |
| One route should stop without conversion  | Exit step        | Completes as exited, no goal             |
| Subscriber state should stop future steps | Global exit rule | Cancels before the guarded step          |

## Goal definitions

A goal definition has a name and optional description and belongs to one workflow. Examples are `Purchased`, `Booked a demo`, or `Activated account`.

The same definition can be referenced by graph goal steps and success goals. Goal names should describe the business outcome, not the UI action that detected it.

## Goal step

Add a **Goal** node when reaching a specific graph path proves success. Select or create the conversion goal in the step panel.

![Goal step configuration selecting the conversion reached by that path](/docs/workflows/goal-step.png)

When a run reaches the node, Lumail:

1. Records the goal on the run.
2. Emits a workflow-goal-reached event.
3. Marks the run completed.
4. Stops routing.

A goal step is terminal and cannot have an outgoing edge.

Use it after a step whose completion is itself the proof, such as an internal qualification path or a branch reached from a matched payment event.

## Success goals

Open **Settings > Goals** to define conversion signals that can occur while the run is active or waiting.

![Success goal settings with event, subscriber state, and completion behavior](/docs/workflows/success-goals.png)

Each success goal contains:

- A reusable goal definition
- A display name for the rule
- An optional subscriber event
- Event-specific filters when supported
- Subscriber-state filters
- A **Complete workflow** switch

The event and every subscriber filter must match together. Those are two layers:

| Layer | Field | Editor control |
| --- | --- | --- |
| Which event | `eventName` + `eventFilters` | Success event. The **Which tag changed** picker pins `eventFilters.tagIds` — it is not Subscriber state. |
| Subscriber state | `filters` | Subscriber state (AND) |

For example:

- Event is **Payment**
- Product is `ai-builder-mobile`
- Subscriber has tag `qualified-lead`

If the conversion is "now has tag X", prefer subscriber state only. That is the visible pin:

```json
{
  "name": "Membre",
  "eventName": null,
  "eventFilters": null,
  "filters": [
    {
      "type": "TAG",
      "field": "tags",
      "operator": "BELONGS_TO_ANY",
      "tagIds": ["tag_member"]
    }
  ],
  "completeWorkflow": true
}
```

If you watch the tag-added event itself, pin `eventFilters.tagIds` (the event picker) **and** repeat the same tag in Subscriber state. Empty `eventFilters.tagIds` matches every tag mutation in the organization. With **Complete workflow** on, that completes every active or waiting run the next time any tag is added.

## Complete or continue

| Setting               | Behavior                                         |
| --------------------- | ------------------------------------------------ |
| Complete workflow off | Record conversion and continue the current route |
| Complete workflow on  | Record conversion and complete immediately       |

Turn completion on when later nurture would be inappropriate after conversion. Leave it off when the workflow should still deliver onboarding or fulfillment content.

## Evaluation order

Success goals are evaluated in the order shown. The first matching goal is recorded. Once a run has `goalReachedId`, later success goals are not recorded for that run.

Only real runs with status **Active** or **Waiting** are watched. Dry runs do not react to live external events and do not contribute to production conversion results.

## Success goals and A/B tests

The A/B dashboard treats a split assignment as successful when the same run records a success goal. Define the conversion before launching the experiment and keep it consistent across variants.

See [A/B Testing](/docs/workflows/workflow-ab-testing) for assignment and rate calculation.

## Goal events as triggers

Reaching a goal emits `subscriber.workflow.goal_reached`. Another Workflow trigger may use that event to start a downstream sequence. Use workflow groups when those sequences must never overlap.

## Naming recommendations

- Prefer outcomes: `Purchased Pro`, `Booked onboarding`, `Activated workspace`.
- Avoid implementation names: `Clicked button 3`, `Reached green node`.
- Keep one definition per business outcome.
- Use the rule name to explain detection details when needed.

## Related documentation

- [A/B Testing](/docs/workflows/workflow-ab-testing)
- [Exit Rules](/docs/workflows/workflow-exit-rules)
- [Triggers](/docs/workflows/workflow-triggers)
- [Test Runs and Results](/docs/workflows/workflow-testing)