Trigger Chain Builder

The Trigger Chain Builder is the visual editor where you design your Trigger Chain’s steps. It provides a flow canvas where each trigger step appears as a node, connected by arrows showing the execution order. You can add steps, configure parameters, create conditional branches, and set up parallel execution — all through a visual interface.

Opening the Builder

1. Go to Trigger Chains in the sidebar.
2. Select a chain in the list.
3. Click Builder in the ribbon toolbar.

Alternatively, double-click a chain in the list to open its builder directly.

The Builder Interface

The builder is divided into two main areas:

Area	Location	Description
Flow Canvas	Left side (main area)	Shows the chain’s steps as connected nodes. Click nodes to select and edit them.
Properties Panel	Right side	Shows the configuration panel for the selected node. Edit parameters, conditions, and settings here.

The builder has a header bar with:

• A back button (←) to return to the Trigger Chains list.
• The title “Trigger Chain Builder”.
• A Save button to save your changes.

The Flow Canvas

The flow canvas displays your chain as a visual flow diagram. Each step is a node (a card), and nodes are connected by arrows showing the execution order.

Node Types

The canvas displays three types of nodes:

Node Type	Appearance	Description
Start Node	Green-bordered card with a play icon	Represents the beginning of the chain. Click it to edit chain settings (name, status, schemas, retry policy).
Trigger Node	Standard card with a commit icon	Represents a single trigger step (e.g., REST API, Email, Database). Click to configure its parameters.
IF Node	Card with a branch icon	Represents a conditional branch. Contains Then and Else sub-branches.
PARALLEL Node	Card with a merge icon	Represents a parallel execution group. Steps inside run concurrently.

Start Node

The Start Node is always the first node in the chain. It represents the beginning of the chain’s execution.

Clicking the Start Node opens the Chain Settings panel with:

Setting	Description
Chain Name	Edit the chain’s display name
Description	Edit the chain’s description
Status	Set to Draft, Active, or Paused
Webhook Secret	Set the HMAC secret for webhook verification
Input Schema	Define expected input variables
Output Schema	Define expected output variables
Timeout (seconds)	Maximum execution time
Max Retries	Number of retries on failure
Backoff (ms)	Initial retry delay
Backoff Multiplier	Backoff multiplier

Trigger Nodes

Each trigger node represents a single action in the chain. The node displays:

• The trigger type (e.g., rest_api, send_email, postgresql)
• The output variable name (if set)
• A Bulk badge for triggers that run once with all data

Click a trigger node to open its configuration in the Properties Panel.

Node Action Buttons

Each node has action buttons:

Button	Icon	Description
Move Left	←	Move this step earlier in the chain
Move Right	→	Move this step later in the chain
Clone	📋	Duplicate this step
Delete	🗑️	Remove this step from the chain

Adding Trigger Steps

Step-by-Step

1. Click the + button at the end of the flow canvas.
2. The Trigger Selector Modal opens, showing all available triggers organized by category.
3. Browse or search for the trigger you need.
4. Click the trigger to add it.
5. The new trigger node appears at the end of the flow.
6. Click the node to configure its parameters in the Properties Panel.

Trigger Categories Available

Category	Triggers
APIs/Webhooks	REST API, GraphQL API, SOAP API
Cloud Storage	AWS S3, GCP Storage, Azure Blob
Databases	PostgreSQL, MySQL, MongoDB
Email	SMTP
File Formats	Export to File, Convert Format, Compress File, Parquet Export, XML Processing, JSONL Export
File Transfer	SFTP, FTPS, WebDAV
Messaging Queues	RabbitMQ, Kafka, AWS SQS
Spreadsheets	Google Sheets, Excel
BI Tools & Alerting	Power BI, Tableau, Slack, Teams, Generic Webhook
ITSM, PM & ERP	JIRA, ServiceNow, SAP
Cloud Orchestration	Azure Data Factory, Dataiku, Airflow
Data Stores & Search	Redis, Elasticsearch, Teradata, Sybase
BI Tools (Extended)	Qlik Sense, Superset, Looker Studio, MicroStrategy
Cloud Warehouses	Snowflake, BigQuery, Databricks, MSSQL, Oracle

IF/ELSE Blocks

IF/ELSE blocks add conditional logic to your chain. They let you execute different steps depending on a condition.

How IF/ELSE Works

An IF block evaluates a condition expression. If the expression returns true, the steps in the Then branch execute. If it returns false, the steps in the Else branch execute.

IF condition is true:
    → Execute Then branch steps
ELSE:
    → Execute Else branch steps

Adding an IF Block

1. Click + on the flow canvas.
2. In the Trigger Selector Modal, look for the Flow Control category.
3. Select IF.
4. An IF node appears with Then and Else branches.
5. Click the IF node to configure the condition expression.
6. Click + Add Step within the Then or Else branch to add steps inside.

Condition Expression

The condition expression is a JavaScript expression that evaluates to true or false. It has access to:

• All output variables from previous steps (via {variable_name} syntax)
• The chain’s input payload (via {input_payload})

Examples:

Expression	What It Checks
{record_count} > 100	Whether more than 100 records were extracted
{api_response.status} == 200	Whether an API returned success
{error_message} == ""	Whether there were no errors
{input_payload.priority} == "high"	Whether the input payload has high priority

IF Node Structure

IF: {record_count} > 100
├── THEN:
│   ├── Send to Database
│   └── Notify Slack
└── ELSE:
    └── Log Warning

Adding Steps Inside Branches

1. Click the IF node.
2. In the Properties Panel, you’ll see the Then and Else sections.
3. Click + Add Step within a branch.
4. Select a trigger from the selector.
5. The step is added inside that branch.

PARALLEL Blocks

PARALLEL blocks allow multiple steps to execute concurrently instead of sequentially. This speeds up chains that have independent steps.

How PARALLEL Works

Steps inside a PARALLEL block run at the same time. The chain waits for all parallel steps to complete before continuing to the next step.

Step 1 (sequential)
    ↓
PARALLEL:
    ├── Send to Database    ← runs at the same time
    ├── Send to Slack       ← runs at the same time
    └── Upload to S3        ← runs at the same time
    ↓
Step 4 (waits for all three to finish)

Adding a PARALLEL Block

1. Click + on the flow canvas.
2. In the Trigger Selector Modal, look for the Flow Control category.
3. Select PARALLEL.
4. A PARALLEL node appears.
5. Click + Add Step within the PARALLEL node to add steps.
6. All steps inside the PARALLEL block will run concurrently.

When to Use PARALLEL

Scenario	Use PARALLEL?
Sending data to multiple independent destinations	✅ Yes
Sending email AND uploading to cloud storage	✅ Yes
Step B depends on Step A’s output	❌ No — use sequential
Writing to database then querying it	❌ No — use sequential

Important: Steps inside a PARALLEL block should be independent. If one step needs the output of another, use sequential execution instead.

Configuring a Trigger Step

When you click a trigger node, the Properties Panel shows its configuration:

Section	Description
Display Name	Editable label for the step
Trigger Type	Shows the trigger type (read-only)
Parameters	Type-specific configuration fields
Output Variable	The variable name where this step’s result is stored

Output Variable Naming

Every trigger step can store its result in an output variable. This variable can be referenced by subsequent steps using {variable_name} syntax.

Field	Description
Output Variable Name	The variable name. Must be unique within the chain. Example: api_response, export_result
Mark output as secret	If checked, the output value is masked in the UI (for sensitive data like API keys)

Example of variable flow:

Step 1: REST API → output_variable: "api_response"
Step 2: Email → body: "API returned: {api_response.status}"
Step 3: Database → query: "INSERT INTO logs VALUES ('{api_response.message}')"

Rename Detection and Reference Updating

When you rename an output variable, RTILA X detects all references to the old name in subsequent steps and asks if you want to update them:

1. You rename api_response to api_result.
2. RTILA X finds all steps that reference {api_response}.
3. A dialog appears: “Renaming this variable will update X references in downstream triggers. Proceed?”
4. Click Rename and Update References to update all references.
5. Click Cancel Rename to keep the old name.

This prevents broken references when you rename variables.

Saving a Chain

Click the Save button in the builder header to save your changes.

What gets saved:

• Chain name, description, and status
• All trigger steps and their configurations
• IF/ELSE conditions and branch contents
• PARALLEL group contents
• Output variable names
• Retry policy and timeout
• Webhook secret
• Input and output schemas

Important: Changes are NOT saved automatically. You must click Save to persist your changes.

Validation Warnings

The builder validates your chain and shows warnings for common issues:

Warning	Cause	How to Fix
Unresolved variable reference	A step references {variable_name} but no previous step produces that variable	Check variable names match, or add the missing step
Duplicate output variable	Two steps use the same output variable name	Rename one of the output variables
Type mismatch	A step expects a list but receives a scalar	Check the data flow between steps

Warnings appear as an expandable panel at the bottom of the builder. Click to expand and see all warnings.

Note: Warnings do not prevent saving. They are informational. However, unresolved references will cause runtime errors when the chain executes.

Tips and Best Practices

Tip	Description
Name your output variables clearly	Use names like db_insert_result instead of result1
Use IF/ELSE for error handling	Check API response codes and branch accordingly
Use PARALLEL for independent destinations	Speed up chains with concurrent steps
Set timeouts	Prevent chains from hanging indefinitely
Test with manual runs	Run the chain manually before scheduling it
Use descriptive step names	Name steps clearly so you can identify them in run history
Check validation warnings	Fix warnings before activating the chain
Keep chains focused	One chain per pipeline. Don’t overload a single chain with too many steps.
Use the rename detection	When renaming variables, always update references to avoid broken chains