A workflow is the path an alert or case follows from the moment it is created until it is closed: who looks at it, what they can do with it, and who signs off. Custom Workflows let you define that path yourself, so different teams and alert types can follow different review, approval and escalation routes.

Every workflow is built from four things. Once you know these, the builder is simple.

One optional layer sits on top of these:

A workflow, then, is just a map: from each status, which actions are available, who can take them, where the alert goes next, and who it goes to.

This guide builds one workflow end to end. It is a common starting point, and the sections that follow refer back to it.

An analyst can close an alert directly or escalate it to a senior reviewer, who then closes it. Any closed alert can be reopened. Your own process may add statuses, actions and approvals on top of this; the last section explains how.

Go to Workflows in the main menu. The Active tab lists your existing workflows, including the default alert workflow and default case workflow that every account starts with. The Library tab holds templates grouped by purpose. Pick one and click Use template, or click Custom workflow to start on a blank canvas.

If you are new to workflows, duplicate the template closest to your process and adjust it. You will still use everything in the next section.

The builder ships with built-in actions (Close, Escalate, Reopen, Set in progress, Put on hold, To review) and built-in statuses (Open, In progress, Escalated, In review, On hold, Closed). If your process needs others, such as an Escalated L2 status for a second review tier, create them before you open the builder:

Once created, they appear in the action and status dropdowns inside the builder and behave like the defaults.

The steps below build the example shown above. Open the builder (Workflows, then Library, then Custom Workflow). The canvas starts with one status, Open, and you add actions from there.

Click the + icon below Open to add a transition. The New transition panel has two parts: If (what happens, and who does it) and Then (where the alert goes, and to whom):

Click Create.

You now have a publishable workflow: Open to Closed, which is the minimum the builder accepts. Everything after this adds control and flexibility.

One thing to know before you go further: when you set By to a single role, the builder also creates a transition for every other role with the same action. You can leave those as they are, or open each one and give that role a different outcome. The maker-checker example later in this guide relies on this.

On any transition, toggle on Requires approval before this action takes effect. This is the maker-checker control. While approval is pending, the alert sits in In review and the approver sees Approve and Reject buttons instead of the usual actions.

Add a second action from Open called Escalate:

The escalation reviewer needs a way out. Add a Close action from Escalated so they can close the alert once their review is done. Without this, the Escalated path is a dead end and the workflow cannot be published.

Add a Reopen action from Closed so any role can bring an alert back to Open if needed, assigned to the Actor.

Four rules apply to every workflow, however simple or complex.

Every path must end in Closed. The builder will not publish a workflow without a transition out of Open and a transition into Closed, so no alert or case can be left in limbo. This holds even when an alert results in a Suspicious Activity Report (SAR): file the SAR, then close the alert.

A status can be used at only one level. If analysts set alerts to In Progress and escalation reviewers also need an in-progress state, create a separate status for the second level, for example In Progress L1. Each tier of review gets its own statuses.

The same action can behave differently depending on who takes it. For example, an Analyst's escalation can require approval while a Team Lead's goes straight to the reviewer. Use this to put tighter controls on junior roles without slowing down senior staff.

The builder does not check permissions. It will let you assign an alert to a role that cannot see the status it lands in, for example assigning a closed alert to an Analyst whose role cannot view closed alerts. Before you publish, check in Team Management that every assignee role can see the statuses your workflow sends it.

The workflow now appears in your Workflow Library with an ID: WA- plus a number for alert workflows, WC- plus a number for case workflows (for example WA-001). Publishing does not yet route any alerts to it; that is the next step.

Versions. Each time you change and republish a workflow, a new version is created. Alerts and cases created from then on use the new version. Alerts and cases already in progress stay on the version they were created with, and cannot be moved to another version from the console.

A published workflow handles alerts only once a rule points to it. There are two ways to connect them.

Set a default for all rules. Go to Settings, then Case management. Under Alert workflow and Case workflow, pick a Default workflow for each. Any rule without its own workflow uses this one, and the default always points to the workflow's latest version. Set the default before custom workflows go live for your account; until it is set, new alerts and cases are created on the built-in default workflow.

Set a workflow for a specific rule. Open the rule, click Edit Rule, go to Alert Creation Details, and under Alert Workflow choose from the dropdown of enabled workflows. Click Save. This is how you give, say, screening alerts one review path and sanctions alerts another.

What each role can see is set separately. A workflow decides which actions a role can take. Which alerts and statuses a role can view is controlled in Team Management; the maker-checker example below shows where this matters.

What changes for reviewers. On an alert that is on a custom workflow, the action buttons are the ones the workflow defines (for example Approve and Reject during an approval) rather than the standard Escalate and Close, and the next assignee is set by the workflow instead of being chosen by hand. Alerts created before the workflow was in place keep the standard buttons and path; these are referred to as legacy alerts below.

Bulk actions on legacy and workflow alerts. Legacy alerts and workflow alerts have different action sets, so they cannot be bulk-actioned together. When an investigator or reviewer selects multiple items in the case or alert table:

The example above gives every role the same path. Some teams have a queue of their own: a maker and a checker who use statuses dedicated for them on alerts they work on eg. onboarding screening. This simple example shows how you can set that up.

The scenario: a queue called Q1 holds two roles, Maker and Checker. The maker moves alerts through In Progress Q1 and Escalated Q1. All other roles move alerts through the standard In Progress and Escalated. Both paths end in Closed.

Go to Settings, then Case management, choose Alerts under Statuses, actions & dispositions, and create two custom statuses: In Progress Q1 and Escalated Q1. The other-roles path uses the built-in In progress and Escalated, so nothing else needs creating.

Open the builder and add the three actions below, each from the status shown. When you set By to Maker, the builder creates the same action for every other role; open those transitions and point them at the standard statuses. Every transition sets Assignee is to Actor. The two paths stay apart because they land in different statuses; the same action, taken by a different role, has a different outcome.

Publish the workflow and assign it to rules as described above.

Publishing the workflow does not control what each role sees on screen. That is set separately. Go to Team Management, open the Checker role, and limit its alert view to, Open, In Progress Q1 and Escalated Q1. Alerts in any other status are then not visible to the checker.

Sign in as a maker and open an alert in Open: taking Set in progress should land the alert in In Progress Q1, assigned to you. Sign in as any other role and take the same action on an Open alert: it should land in In progress. Sign in as a checker: only alerts in the two Q1 statuses should be listed.

All published workflows live in the Workflow Library. You can keep several enabled at once.

Cases work the same way as alerts. Case workflows use the same builder, the same four building blocks and the same rules. The only differences are the WC- ID prefix and that alerts and cases can have fully independent workflows.

If alerts or cases were created on the wrong workflow. This happens when the default was set after alerts had already been created, when the wrong workflow or version was set as default or on a rule, or when a workflow was published with a mistake. Once created, an alert's workflow cannot be changed from the console. First fix the configuration so no new alerts land on the wrong path, and ask reviewers not to action the affected alerts. Then contact Flagright support with: the correct workflow and version, the alert or case IDs affected (or a precise filter such as rule and time range), the status each should be placed in, and, where that status has an assignee, who it should be assigned to.

For any custom action you have created, you can require the reviewer to pick a reason before the action goes through. This is called a disposition. It applies only to actions you have created; the built-in actions and the Approve and Reject buttons cannot be given dispositions.

For the reviewer, a reason picker then appears before the action is applied, showing only the reasons whose scope matches the alert. When a reviewer applies the action to several alerts at once, every alert must match the chosen reason's scope; if any does not, nothing is applied until they pick an unscoped reason or split the selection.

The example in this guide (Open, Escalated, Closed, with Reopen) is one common path, not a required one. The builder is fully configurable, so treat the steps above as a framework and adjust them to your own process.

If your process cannot be expressed with actions, statuses, approvals and assignments as described here, contact your account manager to discuss whether it can be supported in a future release.