> ## Documentation Index
> Fetch the complete documentation index at: https://docs.fraudeg.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Automate Fraud Responses Using Workflow Automation

> Use FraudEG's workflow automation to trigger alerts, create cases, notify teams, and integrate with external systems when fraud signals are detected.

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:

| Trigger                           | Fires when…                                                     |
| --------------------------------- | --------------------------------------------------------------- |
| `transaction.blocked`             | A transaction receives a `block` decision                       |
| `transaction.flagged`             | A transaction is flagged for manual review                      |
| `identity.verification_completed` | An identity verification flow finishes (pass or fail)           |
| `account.risk_detected`           | A user account crosses a configured risk threshold              |
| `case.updated`                    | A fraud case changes status (e.g., opened, resolved, escalated) |

***

## Workflow actions

After a trigger fires, you can execute one or more of the following actions:

| Action                      | Description                                                                 |
| --------------------------- | --------------------------------------------------------------------------- |
| **Send webhook**            | POST the full event payload to any external URL                             |
| **Create fraud case**       | Open a new investigation case in the FraudEG case manager                   |
| **Send email notification** | Deliver a templated email to one or more recipients                         |
| **Trigger Slack alert**     | Post a formatted message to a Slack channel via your connected workspace    |
| **Trigger Teams alert**     | Post a message to a Microsoft Teams channel                                 |
| **Block user account**      | Suspend the user account via your connected identity provider integration   |
| **Add user to watchlist**   | Flag the user in FraudEG's watchlist for elevated scrutiny on future events |

<Tip>
  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.
</Tip>

***

## 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.

<Steps>
  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>
</Steps>

***

## 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:

```text theme={null}
🚨 Transaction blocked
User: {{user.email}}
Amount: {{transaction.amount}} {{transaction.currency}}
Risk score: {{risk_score}}
Signal(s): {{signals}}
Review: https://app.fraudeg.com/cases/{{case.id}}
```

FraudEG interpolates the `{{ }}` placeholders with live values from the event payload at execution time.

<Note>
  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.
</Note>