Building a Workflow
Open a workflow from the Workflows list, or click New workflow, to reach the editor. Click the name in the header to rename the workflow.
The canvas
The editor shows the workflow as a tree on a canvas. The Trigger card is at the top and every enrolled member runs down from it, one step at a time. A step that splits, such as a condition, opens two labeled paths side by side, and each member takes one of them.
- Pan by dragging the background, scrolling, or pressing the arrow keys.
- Zoom with the controls in the top-right corner, or hold ⌘ (Ctrl on Windows) while scrolling. Fit to view brings the whole tree back on screen.
- Add a step by clicking a + on any line. A menu lists the step types, grouped into Flow and Actions. Steps added by enabled packages appear in their own groups.
- Edit a step by clicking its card. Its settings open in a drawer. Click Done to keep your changes or Cancel to discard them.
- Move or delete a step from the ⋯ menu on its card: Move up, Move down, or Delete. Deleting a step with paths also deletes every step inside those paths, and Allegro asks you to confirm first.
Cards are laid out for you and can't be dragged. A step with paths is always the last step in its column. To continue after it, add steps inside each path. A path with no steps shows Run ends, and a member who reaches it finishes the workflow.
The trigger
Click the Trigger card to choose what starts the workflow.
| Field | What it does |
|---|---|
| Event | The event that enrolls a member. Start typing to search the event list, or type any event name. See Which events can trigger a workflow. |
| Only enroll when | Optional conditions. A member enrolls only when they match. Leave it empty to enroll on every matching event. |
The event list groups suggestions into Tracked events, Platform events, and a group per enabled package. Tracked events seen recently show roughly how often they fired in the last 30 days. Platform events carry a webhooks tag, since they are the same events webhooks deliver.
You can type an event name that isn't in the list yet, so you can build a workflow before your site starts sending the event.
Steps
Condition
Sends each member down the Yes or No path, depending on whether they match a set of conditions when they reach the step.
Delay
Waits a fixed time before the next step: a number of minutes, hours, or days, up to 90 days.
Wait for event
Pauses until the member does something, or gives up after a set time, then branches on which came first.
| Field | What it does |
|---|---|
| Event | The event to wait for. |
| Give up after | How long to wait before the member takes the timed-out path, up to 90 days. |
| Occurrences | Optional. How many matching events must happen before the member continues, from 1 to 100. Leave it at 1 for most uses. |
| Only count events where | Optional conditions checked against each awaited event. Events that don't match aren't counted. |
The step opens two paths:
- Event happened: the member fired the event (the set number of times) before the timeout.
- Timed out: the time ran out first.
Exactly one path is taken, even when the event and the timeout land at the same moment.
Send email
Sends the member one of your workflow emails. Pick the email from the list. The card shows a preview of the email and its name.
Sender chooses who the email comes from. Leave it on Default sender to use the default sender, or pick one of your senders.
If the email has its own variables, the step
shows a field for each one under Email variables. Type the value this
workflow should send. A value can use placeholders, such as {% event.coupon %}
to pass along a field from the event. Fields marked with an asterisk have no
default, so the workflow can't be published until you fill them in. Leave any
other field empty to send the email's default.
A member without an email address skips the step and carries on. So does a member who opted out of marketing email, or of the email's topic, when the email is a marketing one. The run records why the step was skipped.
Update segment
Adds the member to a segment or removes them from one.
| Field | What it does |
|---|---|
| Action | Add to segment or Remove from segment. |
| Segment | The segment to change. Only segments whose members are added and removed directly are listed, not rule-based ones. |
| Expires after | Optional, when adding. The member leaves the segment again after this long. Leave it empty to keep them in it. |
Update user attribute
Sets or clears a user attribute on the member.
| Field | What it does |
|---|---|
| Attribute | The attribute to change. |
| Value | The value to store. It must fit the attribute's type and validation rules. |
| Clear the value instead | Removes the member's value instead of setting one. |
End
Stops the workflow for the member. Use it to end one path early, for example on the No path of a condition. Reaching the bottom of any path ends the run the same way.
Naming paths
The drawer for a step with paths has a Paths section where you can rename each path, for example "Purchased" and "No purchase within 1 hour". The names appear on the canvas. Leave a name empty to use the default.
Conditions
Trigger conditions, condition steps, and wait-for-event filters use the same condition builder as interaction targeting. Workflows can test:
- Member data: profile fields, user attributes, entitlements, segments, and fields from enabled packages.
- The organization's clock: time, date, and day of the week in your organization's time zone.
- The event: its name, a field from its data (nested fields use dots, as
plan.tier), the property it happened on, the path of the page it happened on, and a UTM parameter on that page.
The event attributes read the event that started the run. In a wait-for-event filter they read the awaited event instead.
Attributes that depend on a live page visit, such as the visitor's device, location, or local time, and cohorts aren't available, because a workflow runs in the background without a visitor on the page.
Settings
Click Settings beside the canvas to open the workflow's settings panel.
| Setting | What it does |
|---|---|
| Properties | Which properties the workflow runs on. Leave all unchecked to run on every property. |
| Enrollment | How often one member can enter the workflow. See below. |
| Cooldown | Shown for Once per cooldown. How long after a member's last run finishes before they can enroll again. |
| Exit event | Optional. When this event happens for a member who is in the workflow, their run ends right away. |
| Include imports and syncs | Also enroll members from events that imports and integration syncs record, not just what they do on your sites. Off by default. See System events. |
Enrollment modes
| Mode | Behavior |
|---|---|
| Once per member | The default. A member enters the workflow at most once, ever, including runs that were canceled or have since been removed from the run history. |
| Every time | Every matching event starts a new run, but never two at once: an event that arrives while the member already has a run in progress is ignored. |
| Once per cooldown | Like Every time, but the member can't enroll again until the cooldown has passed since their last run finished. |
Properties and the exit event
When a workflow is limited to some properties, only events from those properties start runs or move a waiting run forward. An event with no property, such as some platform events, doesn't start a run in a property-limited workflow.
The exit event applies no matter which property it comes from, and whatever its source, so a purchase anywhere stops an abandoned-checkout reminder.
Saving and publishing
| Button | What it does |
|---|---|
| Save draft | Saves without going live. Shown while the workflow is a draft. |
| Save & publish | Saves and makes the workflow live, so it starts enrolling members. Press ⌘S (Ctrl+S on Windows) to do the same. On a published workflow it asks for an optional revision note. |
Both check the whole workflow first. If something is wrong, the steps that need attention are outlined in red. Select one to see what to change in its drawer.
Each publish creates a new version. Runs already in progress keep following the version they started on, and new runs follow the new one.
The ⋯ menu in the header also has:
| Action | What it does |
|---|---|
| Rename | Moves focus to the name in the header. |
| Duplicate | Copies the workflow as a new draft. |
| Unpublish | Stops enrolling members and turns the workflow back into a draft. If members are in it, the dialog offers to Also cancel their runs. That box is checked by default. |
| Archive | Stops enrolling members and cancels every run in progress. Archived workflows can be restored from the list as drafts. |
An email can't be removed from the workflow emails list while a published workflow sends it. Publishing fails if a step points at an email that has been deleted.
Undo and editing together
The undo and redo buttons in the header step back and forward through your unsaved changes.
Only one person can edit a workflow at a time. If someone else has it open, the editor is read only and a banner offers to take over editing.
Permissions
Viewers can see the Workflows list, runs, emails, and topics, but can't open the editor. Members and admins can create, edit, test, publish, and archive workflows, act on runs, and manage workflow emails, topics, and opt-outs. See Permissions.