Workflow Groups
Configure mutual exclusion, conflict strategies, chaining, and Workflow group tools.
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
- You create a group and choose a conflict resolution strategy.
- You assign workflows to that group via Workflow Settings.
- 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.
- 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
- Open any workflow and click Actions > Settings.
- In the Workflow Group section, click the New button.
- Enter a group name and pick a conflict resolution strategy.
- 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:
- Call
list_workflow_groups; never invent agroupId. - Call
get_workflow_groupand preserve its exactupdatedAtbefore updating or deleting. - Call
get_workflowand preserve its exactupdatedAtbefore assigning or detaching. - Create, update, or assign the group.
- Read both the group and workflow back to verify the result.
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:
- Tour A starts and remains the only active workflow in the group.
- Its final action adds
tour-b. - Lumail marks Tour A as completed.
- Lumail evaluates the
tour-btrigger and enrolls the subscriber in Tour B. - 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 - Overview of workflow setup
- Manual enrollment - Bulk add from the subscribers list still respects group rules
- Action Step - "Add to Workflow" action respects group rules
- Create Subscriber - API enrollment and
triggerWorkflows