Skip to main content
Workflows are automated sequences of actions that FraudEG executes in response to fraud events or decisions. Where risk rules determine the outcome of a transaction — allow, challenge, or block — workflows act on those outcomes. They bridge your fraud prevention layer with the rest of your operations: notifying your fraud team on Slack, opening a Jira ticket for manual review, blocking a user account in your identity system, or firing a webhook to a downstream service. You define the trigger, apply optional filters, and chain together as many actions as you need.

​
Rules vs. workflows

It helps to think of rules and workflows as two complementary layers:
  • Risk rules answer the question “What decision should we make about this event?”
  • Workflows answer the question “What should we do because of that decision?”
A rule might block a transaction. A workflow then creates a fraud case, sends a Slack alert to your risk team, and adds the user to a watchlist — all automatically, with no manual intervention required.

​
Workflow triggers

Every workflow starts with a trigger — an event that FraudEG listens for. The following triggers are available:

​
Workflow actions

After a trigger fires, you can execute one or more of the following actions:
You can chain workflows together. For example, a Create fraud case action triggers a case.created event, which can itself be the trigger for a second workflow — such as notifying a senior analyst or escalating based on transaction value. Keep each workflow focused on a single responsibility and chain them for complex logic.

​
Build a workflow

Open the no-code workflow builder at Platform → Workflows. You can create as many workflows as you need, and enable or disable them independently.
1

Create a new workflow

Go to Platform → Workflows and click Create Workflow. Give the workflow a clear name — for example, High-risk transaction alert — and an optional description.
2

Select a trigger event

Choose the event that should start this workflow from the Trigger dropdown. For example, select transaction.blocked to fire whenever FraudEG blocks a transaction.
3

Add conditions (optional)

Click Add Condition to filter which events actually proceed to the action step. You can filter by risk_score, transaction amount, specific signals, user attributes, or any field in the event payload. If you skip this step, every matching trigger event will run the workflow.
4

Add one or more actions

Click Add Action and select what should happen. Add as many actions as needed — they execute in order. For webhook actions, paste the destination URL and optionally customize the payload template.
5

Test with a sandbox event

Before enabling the workflow, click Test Workflow and select a recent sandbox event or manually enter a test payload. FraudEG runs the workflow in simulation mode and shows you the result of each action — including the full webhook request and response if applicable.
6

Enable the workflow

Once your test passes, toggle the workflow to Enabled. It will immediately begin responding to live or sandbox events depending on your active environment.

​
Example: High-risk transaction alert

Here is a complete example of a workflow that notifies your fraud team the moment a high-value transaction is blocked:
  • Name: High-risk transaction alert
  • Trigger: transaction.blocked
  • Condition: amount > 10000
  • Action: Send Slack message to #fraud-alerts channel
The Slack message template might look like this:
FraudEG interpolates the {{ }} placeholders with live values from the event payload at execution time.
Every workflow execution — successful or failed — is logged in Platform → Workflows → Execution Logs. Each log entry records the trigger event, the conditions evaluated, each action attempted, and the full request/response for webhook actions. Use these logs to debug unexpected behaviour or audit workflow activity.