> ## Documentation Index
> Fetch the complete documentation index at: https://docs.datalex.solutions/llms.txt
> Use this file to discover all available pages before exploring further.
# Workflow Nodes
> Reference for all node types available on the workflow canvas — triggers, integrations, and actions.
# Workflow Nodes
Nodes are the fundamental building blocks of a Datalex workflow. Each node represents a discrete step in your fraud detection or routing logic. Nodes are connected by edges to form a directed graph that is evaluated in real time against incoming transaction data.
*The Datalex workflow canvas with a sample node graph.*
***
## Node Categories
The node palette is organized into three categories: **Triggers**, **Integrations**, and **Actions**. Drag any node from the side panel onto the canvas to add it to your workflow.
| Category | Purpose |
| ------------ | ------------------------------------------------------- |
| Triggers | Evaluate conditions and route execution |
| Integrations | Enrich transactions with external or computed signals |
| Actions | Terminate a branch with a final decision or side-effect |
***
## Input Node
Every workflow begins with exactly one **Input Node**. This node defines the transaction attributes that are available to all downstream nodes.
*The Input Node with configured attributes.*
**How it works:**
* Attributes are declared as typed fields (e.g., `Text`, `Number`, `Boolean`).
* Any attribute added here becomes available in condition rules throughout the workflow.
* Common attributes include payment details, merchant information, card data, and user context.
**Configuration:**
1. Click the Input Node on the canvas to open the Attribute Editor.
2. Add attributes by specifying a name, type, and description.
3. Elements added here are added as additional params to eb used in input fields on top of the predefined ones
4. Save — the attributes are immediately available to all Condition Nodes.
***
## Condition Node
A **Condition Node** evaluates one or more rules against the transaction data and routes execution to different branches based on the outcome.
*A Condition Node with two rules configured: a passing branch (#1) and a failing branch (#2).*
**Rule structure:** Each rule consists of:
* **Attribute** — the data field to evaluate (e.g., `paymentInfo.amount`)
* **Operator** — the comparison logic (see table below)
* **Value** — the threshold or target value
**Supported operators:**
| Operator | Description |
| -------------- | ------------------------------- |
| `EQUAL` | Exact match |
| `NOT_EQUAL` | Does not match |
| `GREATER_THAN` | Numeric greater-than comparison |
| `LESS_THAN` | Numeric less-than comparison |
| `IN_LIST` | Check against a list |
| `NOT_IN_LIST` | Check against a list |
| `IS_NULL` | Field is absent or null |
| `IS_NOT_NULL` | Field is present and not null |
**Outputs:**
* **Branch #1 (green)** — all rules evaluate to `true`.
* **Branch #2 (red)** — one or more rules evaluate to `false`.
* Additional custom branches can be added for more complex routing.
> A Condition Node must have at least one fully configured rule before you can save the workflow.
***
## Action Nodes
Action Nodes terminate a branch with a decision or trigger a side-effect. They have no outgoing connections.
### Allow
Marks the transaction as approved. Execution stops on this branch.
### Reject
Marks the transaction as rejected. Execution stops on this branch.
### Node Options
Selecting a node allows for specifying additional parameters such as flagging the transaction or adding an insight which is like a note. Additionally, a toggle option is provided to create a case.
### Create Case
Opens a new investigation case in the Case Management module and links it to the triggering transaction.
**Configuration options:**
* **Case name / reason** — a descriptive label for the generated case.
* **Priority** — `LOW`, `MEDIUM`, `HIGH`, or `CRITICAL`.
* **Assigned investigator** — optional pre-assignment.
***
## Integration Nodes
Integration Nodes enrich the transaction context with computed or externally fetched signals. Their outputs become available as attributes in downstream Condition Nodes.
### Velocity
Counts how many times a given attribute value (e.g., a card fingerprint) has appeared within a configurable rolling time window.
**Configuration:**
* **Attribute** — the field to track (e.g., `card.fingerprint`).
* **Time window** — the look-back duration (e.g., 5 minutes, 1 hour, 24 hours).
* **Threshold** — the count that defines high velocity.
**Output:** The computed velocity count is injected as a new attribute that can be referenced in subsequent Condition Nodes.
***
### Device
Performs device fingerprint analysis to detect anomalous device behaviour, reused devices across multiple accounts, or unusual browser/OS combinations.
**Evaluated signals:**
* Device fingerprint
* Browser and operating system
* Device velocity (number of transactions from the same device in a time window)
* Known suspicious device flags
***
### IP Lookup (VPN Detection)
Resolves the transaction IP address and checks whether it originates from a known VPN, Tor exit node, data-centre range, or IP blocklist.
**Configuration:**
* Toggle individual detection categories (VPN, Tor, proxy, data-centre).
* Set the desired action on a positive match (route to specific branch).
**Output attributes:**
* `vpn.isVpn` — boolean
* `vpn.isTor` — boolean
* `vpn.isProxy` — boolean
* `vpn.country` — detected country from IP geolocation
***
### Country Block
Allows or restricts transaction processing based on the geographic origin of the transaction.
**Configuration:**
* Select a list of allowed or blocked countries.
* Choose whether unrecognized countries are treated as blocked or allowed.
***
### Custom API (Integration)
Calls an external REST API and maps the response fields to workflow attributes, enabling integration with any third-party data source.
**Configuration:**
* **Endpoint URL** — the target REST endpoint.
* **HTTP method** — `GET` or `POST`.
* **Headers and payload** — static or dynamic values using `{{ attribute }}` syntax.
* **Response mapping** — define which response fields become workflow attributes.
***
### Sub-Workflow
Embeds a previously saved workflow as a reusable step inside the current workflow.
**Use cases:**
* Shared compliance checks reused across multiple workflows.
* Modular fraud checks that can be updated independently.
**Configuration:**
* Select the target workflow from the dropdown list.
* The sub-workflow receives the same input attributes as the parent.
***
## Node Validation Rules
Before a workflow can be saved or activated, the following structural rules are enforced:
1. Exactly one **Input Node** must be present.
2. At least one **Action Node** (Allow, Reject, etc.) must be reachable.
3. Every node except the Input Node must be connected to at least one edge.
4. All **Condition Nodes** must have at least one fully configured rule (attribute, operator, and value).
5. **Sub-Workflow Nodes** must reference a valid, saved workflow.
Validation errors are surfaced inline on the canvas and in the save dialog.
***
## Adding a Node
1. Open the node palette from the left-hand sidebar.
2. Drag the desired node type onto the canvas.
3. Connect it to an existing node by dragging from the source handle (bottom of a node) to the target handle (top of a node).
4. Click the node to open its configuration panel.
5. Save the workflow.
*Dragging a Condition Node from the palette onto the canvas.*