When subscribers match triggers for several workflows, they can end up receiving too many emails at the same time. Workflow groups solve this by making workflows **mutually exclusive** - a subscriber can only be active in one workflow per group.

## How It Works

1. You create a **group** and choose a conflict resolution strategy.
2. You assign workflows to that group via **Workflow Settings**.
3. Whenever a subscriber is about to be enrolled in a workflow that belongs to a group, the system checks if the subscriber is already active in another workflow from the same group.
4. If there is a conflict, the chosen strategy decides what happens.

Workflows without a group are unaffected and work independently.

## Conflict Resolution Strategies

Each group has one strategy that applies to every conflict within that group.

### Latest Wins (CANCEL_EXISTING)

The new workflow takes priority. All active workflows in the group are canceled for that subscriber, and the new workflow starts normally.

**Use when:** the most recent workflow is always the most relevant (e.g. re-onboarding after a plan change).

### First Wins (SKIP_NEW)

The existing workflow keeps running. A conflicting enrollment from an unrelated trigger is skipped.

When the existing workflow's **final action adds a tag that triggers the next workflow in the same group**, Lumail waits for the current workflow to complete and then evaluates the next enrollment. This lets you chain mutually exclusive funnel stages without running two stages at once.

**Use when:** you want to protect an in-progress sequence from being interrupted (e.g. a 7-day welcome series should finish before anything else starts).

### Send First Email Only (RUN_FIRST_STEP)

If the subscriber is already enrolled in another workflow from the group, they are **not** enrolled in the new one - but the first email step is still sent as a standalone message. This way the subscriber gets the initial email without going through the full sequence.

**Use when:** you want to acknowledge the trigger without committing to a full workflow (e.g. send a quick "thanks for signing up" even though a welcome series is already running).

## When Conflicts Are Checked

The mutual exclusion check runs in **all enrollment paths**:

- Tag-based triggers (subscriber gets a tag that matches a workflow trigger)
- Inngest subscriber events
- "Add to Workflow" action steps inside other workflows
- Manual enrollment via the AI assistant
- Bulk "Add to Workflow" from the subscribers list
- API-driven enrollment

## Important Behavior

- **Active or waiting runs conflict.** Completed, canceled, and failed runs do not create a permanent lock.
- **A terminal Add Tags action is evaluated after completion.** The tag is added immediately, but workflows triggered by that tag are evaluated once the emitting run is complete.
- **A non-terminal Add Tags action is evaluated immediately.** If another workflow in the group is still active, First Wins skips that enrollment as usual.
- **Groups are per-organization.** Each organization manages its own groups independently.
- **Group names are unique** within an organization. Workflow creation and updates reject case-insensitive duplicates.
- **Renaming preserves membership.** Existing runs keep their status, while future enrollments use the updated group.
- **Removing a workflow from a group** (setting group to "No group") has no effect on subscribers already enrolled - it only affects future enrollments.
- **Deleting a group** automatically removes the group assignment from all workflows (they become ungrouped). No active workflows are interrupted.

## Creating a Group

1. Open any workflow and click **Actions > Settings**.
2. In the **Workflow Group** section, click the **New** button.
3. Enter a group name and pick a conflict resolution strategy.
4. Click **Create group**. The new group is automatically selected for this workflow.

You can also assign existing groups to other workflows from their individual settings dialogs.

## Managing Workflow groups with an agent or CLI

Workflow group tools are available for every organization.

| Tool                    | Purpose                                                                   |
| ----------------------- | ------------------------------------------------------------------------- |
| `list_workflow_groups`  | Discover group IDs, names, strategies, counts, and concurrency timestamps |
| `get_workflow_group`    | Inspect assigned workflows, active-run counts, and conflict strategy      |
| `create_workflow_group` | Create a group; retries are idempotent when name and strategy match       |
| `update_workflow_group` | Rename or change strategy after a fresh read                              |
| `set_workflow_group`    | Assign or detach a workflow without replacing its graph                   |
| `delete_workflow_group` | Permanently delete a group through the confirmation flow                  |

Safe sequence:

1. Call `list_workflow_groups`; never invent a `groupId`.
2. Call `get_workflow_group` and preserve its exact `updatedAt` before updating or deleting.
3. Call `get_workflow` and preserve its exact `updatedAt` before assigning or detaching.
4. Create, update, or assign the group.
5. Read both the group and workflow back to verify the result.

```bash
lumail tools run list_workflow_groups \
  --account <org> \
  --params '{}'

lumail tools run create_workflow_group \
  --account <org> \
  --params '{"name":"Onboarding","conflictStrategy":"SKIP_NEW"}'

lumail tools run set_workflow_group \
  --account <org> \
  --params '{"workflowId":"workflow-id","expectedUpdatedAt":"2026-07-27T10:00:00.000Z","groupId":"group-id"}'
```

`set_workflow_group` changes only the group assignment. It does not replace the graph, publish, activate, enroll, or send.

Group deletion is destructive and confirmation-gated. The tool requires the expected name and timestamp, refuses to delete a group with assigned workflows by default, and requires `unassignWorkflows: true` before using the database's `SET NULL` behavior. Existing runs are never canceled by group deletion.

## Example

You have three workflows:

| Workflow       | Group      | Status |
| -------------- | ---------- | ------ |
| Welcome Series | Onboarding | Active |
| Re-engagement  | Onboarding | Active |
| Product Tips   | _(none)_   | Active |

The Onboarding group uses **First Wins**.

- A subscriber triggers Welcome Series and starts receiving emails.
- While still active in Welcome Series, the same subscriber triggers Re-engagement. Because of First Wins, the enrollment is **skipped** - Welcome Series continues uninterrupted.
- The same subscriber triggers Product Tips. Since Product Tips has **no group**, it starts normally - groups only affect workflows within the same group.
- Once Welcome Series completes, the subscriber triggers Re-engagement again. This time there is no active conflict, so Re-engagement starts.

## Chaining a funnel with tags

Use a final **Add Tags** action when one stage should hand the subscriber to the next stage.

For example, your Grand Tour contains four workflows in the `Grand Tour` group, using **First Wins**:

| Workflow | Trigger            | Final action        |
| -------- | ------------------ | ------------------- |
| Tour A   | Tag `tour-a` added | Add tag `tour-b`    |
| Tour B   | Tag `tour-b` added | Add tag `tour-c`    |
| Tour C   | Tag `tour-c` added | Add tag `tour-d`    |
| Tour D   | Tag `tour-d` added | Add tag `tour-done` |

When a subscriber receives `tour-a`:

1. Tour A starts and remains the only active workflow in the group.
2. Its final action adds `tour-b`.
3. Lumail marks Tour A as completed.
4. Lumail evaluates the `tour-b` trigger and enrolls the subscriber in Tour B.
5. The same handoff repeats until Tour D completes.

At no point are Tour A and Tour B active together. The tag remains visible in the subscriber timeline when it is added; only the next enrollment waits for completion.

If **Add tag `tour-b`** appears before the final step, First Wins still evaluates it immediately and skips Tour B because Tour A is active. Move the handoff tag to the final action when you want sequential chaining.

## Related Documentation

- [Creating Workflows](/docs/workflows) - Overview of workflow setup
- [Manual enrollment](/docs/workflows/workflow-manual-enrollment) - Bulk add from the subscribers list still respects group rules
- [Action Step](/docs/workflows/workflow-action-step) - "Add to Workflow" action respects group rules
- [Create Subscriber](/docs/api-reference/api-subscribers-post) - API enrollment and `triggerWorkflows`