Trigger Chains Overview

Trigger Chains are a new feature in RTILA X v8.3.2 that let you build reusable, multi-step post-processing pipelines. Instead of configuring triggers inside each individual project, you create a standalone chain of actions that can be triggered by any project, run on a schedule, or called from an external webhook.

Think of a Trigger Chain as a recipe for what happens after your data is collected. Your automation scrapes the data (the ingredients), and the Trigger Chain processes, transforms, and delivers that data to its final destinations (the finished dish).

What Are Trigger Chains?

A Trigger Chain is a reusable sequence of post-execution actions that processes data after your automation runs. Each chain is a standalone entity that can be:

• Triggered by project completion — Automatically runs after a project finishes scraping.
• Triggered manually — Run on demand from the RTILA X interface.
• Triggered by schedule — Run on a recurring schedule (every N minutes, hours, daily, or weekly).
• Triggered by webhook — Called from external services via an HTTP request.

A chain contains an ordered list of trigger steps, each performing a specific action: sending data to an API, uploading to cloud storage, writing to a database, sending an email, and so on. Steps can include conditional logic (IF/ELSE) and parallel execution groups.

How Trigger Chains Differ from Project Triggers

RTILA X has two trigger systems. Understanding the difference helps you choose the right one:

Feature	Project Triggers	Trigger Chains
Where configured	Inside each project’s settings	Standalone, separate from any project
Reusability	Tied to one project	Can be triggered by any project, schedule, or webhook
Conditional logic	No	IF/ELSE blocks with expressions
Parallel execution	No	PARALLEL blocks for concurrent steps
Scheduling	Tied to project schedule	Independent schedule
Webhook triggering	No	Yes, via API key and webhook secret
Run history	Limited	Detailed run history with step-by-step tracking
Checkpoint & resume	No	Yes, failed runs can be resumed
Retry policy	No	Configurable retry with backoff
Input/Output schemas	No	Defined input/output schemas

When to use Project Triggers: Simple, single-project data delivery. Example: “After scraping Amazon, send the data to my database.”

When to use Trigger Chains: Complex, reusable, multi-step pipelines. Example: “After scraping, check if the data has more than 100 records. If yes, send to the database AND notify Slack in parallel. If no, just log it.”

Chain Structure

Every Trigger Chain is made up of the following components:

Field	Type	Description
name	String	The display name of the chain. Shown in the chain list and notifications.
description	String	Optional description explaining what the chain does.
status	String	The chain’s current status: draft, active, or paused.
triggers	JSON Array	An ordered list of trigger steps, each with its own type, parameters, and configuration.
retry_policy	JSON Object	Configuration for automatic retries on failure. Includes max retries, backoff delay, and backoff multiplier.
timeout_seconds	Number	Maximum time (in seconds) the chain is allowed to run before being force-terminated. Leave empty for no timeout.
api_key	String	API key for remote triggering via webhook. Auto-generated when remote execution is enabled.
webhook_secret	String	Optional HMAC secret for verifying webhook request signatures. Adds an extra layer of security.
input_schema	JSON Array	Defines the expected input variables when the chain is triggered. Each entry has a name, type, and description.
output_schema	JSON Array	Defines the expected output variables produced by the chain. Each entry has a name, type, and description.
remote_enabled	Boolean	Whether the chain can be triggered remotely via webhook.
owner	Relation	The user profile that owns the chain.
created	Date	When the chain was created.
updated	Date	When the chain was last modified.

Chain Statuses

Every Trigger Chain has one of three statuses:

Status	Icon Color	Description
draft	Grey	The chain is being built. It cannot be triggered until set to active. Use this status while you’re still configuring the chain.
active	Green	The chain is ready and can be triggered. Scheduled runs, project triggers, and webhooks will execute it.
paused	Orange	The chain is temporarily disabled. It will not execute when triggered, but its configuration is preserved. Set back to active to resume.

Changing a Chain’s Status

1. Go to Trigger Chains in the sidebar.
2. Select the chain in the list.
3. Click Builder in the ribbon to open the chain editor.
4. In the chain settings panel (the Start node), change the Status dropdown.
5. Click Save.

Creating a Trigger Chain

Step-by-Step

1. Click Trigger Chains in the sidebar.
2. Click New in the ribbon toolbar.
3. The Create Chain dialog appears.
4. Enter a Name for the chain (e.g., “Product Data Pipeline”).
5. Optionally enter a Description.
6. Select the initial Status (usually draft while you’re building).
7. Click Create.
8. The chain is created and you are taken to the Trigger Chain Builder to add steps.

What Happens After Creation

• The chain appears in the Trigger Chains list.
• You are automatically redirected to the Trigger Chain Builder to configure the chain’s steps.
• The chain starts in draft status. You must set it to active before it can be triggered.

The Trigger Chains List Page

The Trigger Chains list page shows all your chains in a table:

Column	Description
Name	The chain’s display name. A cloud icon appears next to chains with remote execution enabled.
Status	Shows active (green), paused (orange), or draft (grey).
Triggers	The number of trigger steps in the chain.
Schedule	Shows the schedule if one is configured (e.g., “Every 5 minutes”, “Daily at 09:00”). Shows “No schedule” if none.
Last Run	The status of the most recent run (e.g., completed, failed). Shows “Never” if the chain has never been run.

Interacting with the List

Action	How
Select a chain	Click on its row
Open the builder	Double-click the row, or select it and click Builder
Run the chain	Select it and click Run
View run history	Select it and click Runs
Configure schedule	Select it and click Schedule
Configure remote access	Select it and click Remote
Delete the chain	Select it and click Delete

Ribbon Toolbar

The Trigger Chains page has a ribbon toolbar divided into groups:

Chain Group

Button	Description
New	Creates a new trigger chain

Execution Group

Button	Description
Run	Manually triggers the selected chain
Runs	Opens the run history page for the selected chain

Configure Group

Button	Description
Builder	Opens the visual Trigger Chain Builder
Schedule	Opens the scheduling configuration
Remote	Opens the remote execution settings

Manage Group

Button	Description
Delete	Deletes the selected chain (with confirmation)

Chain Settings

Chain settings are configured in the Start node of the Trigger Chain Builder. When you click the Start node, a settings panel appears with:

Setting	Description
Chain Name	The display name of the chain
Description	Optional description
Status	Draft, Active, or Paused
Webhook Secret	HMAC secret for webhook signature verification
Input Schema	Define expected input variables
Output Schema	Define expected output variables
Timeout	Maximum execution time in seconds
Max Retries	Number of automatic retries on failure
Backoff (ms)	Initial delay before retry, in milliseconds
Backoff Multiplier	Multiplier applied to backoff delay between retries

Retry Policy

The retry policy controls what happens when a trigger step fails:

Parameter	Description	Default
Max Retries	How many times to retry a failed step before giving up. Set to 0 to disable retries.	0
Backoff (ms)	The initial delay before the first retry, in milliseconds.	1000
Backoff Multiplier	Each subsequent retry waits previous_delay × multiplier milliseconds. For example, with backoff 1000ms and multiplier 2.0, retries wait 1s, 2s, 4s, 8s…	2.0

Example retry sequence (max_retries: 3, backoff_ms: 1000, multiplier: 2.0):

1. Step fails → wait 1 second → retry 1
2. Retry 1 fails → wait 2 seconds → retry 2
3. Retry 2 fails → wait 4 seconds → retry 3
4. Retry 3 fails → chain step is marked as failed

Remote Execution

Trigger Chains can be triggered remotely via HTTP webhooks. This allows external services (like Zapier, Make.com, or custom scripts) to trigger your chain.

Enabling Remote Execution

1. Go to Trigger Chains and select a chain.
2. Click Remote in the ribbon.
3. Toggle Enable Remote Execution to on.
4. An API key is generated automatically.
5. The Webhook URL is displayed.

Remote Execution Fields

Field	Description
remote_enabled	Whether the chain can be triggered via webhook
api_key	A unique API key for authenticating webhook requests. Auto-generated when remote execution is enabled. Can be regenerated at any time.
webhook_secret	Optional HMAC secret for verifying webhook request signatures

Webhook URL Format

The webhook URL for triggering a chain remotely is:

POST http://YOUR_RTILA_URL/api/rtila/webhook/{chain_id}

Replace YOUR_RTILA_URL with your RTILA X server URL and {chain_id} with the chain’s ID.

Request Headers

Header	Description
X-Api-Key	Your chain’s API key. Required.
Content-Type	Must be application/json. Required.
X-Webhook-Signature	HMAC-SHA256 signature of the request body, using your webhook secret. Required if webhook_secret is set.

Request Body

{
  "input_payload": {
    "key": "value",
    "data": "..."
  }
}

The input_payload object is passed to the chain as its input data.

Webhook Security (webhook_secret)

When you set a webhook_secret on a chain, RTILA X verifies that incoming webhook requests are genuine:

1. The external service computes an HMAC-SHA256 signature of the raw request body using your webhook secret.
2. The signature is sent in the X-Webhook-Signature header.
3. RTILA X computes its own signature and compares.
4. If the signatures don’t match, the request is rejected with a 401 Invalid webhook signature error.

This prevents unauthorized parties from triggering your chain, even if they know the webhook URL.

Regenerating the API Key

If your API key is compromised:

1. Select the chain.
2. Click Remote in the ribbon.
3. Click Generate New Key.
4. A new API key is generated. The old key immediately stops working.

Input and Output Schemas

Trigger Chains can define input schemas and output schemas to document what data flows in and out of the chain.

Input Schema

The input schema defines the variables that the chain expects to receive when triggered. Each input variable has:

Field	Description
name	The variable name (e.g., scraped_data, target_url)
type	The data type: string, integer, float, boolean, object, array, or any
description	A description of what this variable contains

Output Schema

The output schema defines the variables that the chain produces after execution. The structure is the same as the input schema.

Why Use Schemas?

Schemas serve as documentation for your chains. They tell anyone reading the chain what data it expects and what it produces. This is especially useful when:

• Multiple team members work on the same chain.
• External services trigger the chain via webhook and need to know what data to send.
• You’re reviewing old chains and need to understand what they do.

Trigger Chain Schedules

Trigger Chains can run on a schedule, independent of any project. See Trigger Chain Scheduling for complete documentation.

Deleting a Trigger Chain

1. Go to Trigger Chains.
2. Select the chain.
3. Click Delete in the ribbon.
4. A confirmation dialog appears.
5. Click Delete to confirm.

Warning: Deleting a chain also deletes:

• All its trigger step configurations.
• Its schedule (if any).
• Its run history.

This action cannot be undone.

Tips and Best Practices

Tip	Description
Start in draft status	Build your chain in draft status. Test it thoroughly before setting to active.
Use descriptive names	Name chains clearly (e.g., “Daily Product Sync to Database”) so you can identify them in the list.
Add descriptions	Write a brief description explaining what the chain does. Future you will thank you.
Set a timeout	Set a timeout to prevent chains from running forever if something hangs.
Configure retry policy	Set max_retries to 1–3 for chains that call external APIs, which may have transient failures.
Use webhook secrets	Always set a webhook secret for chains triggered by external services.
Test before activating	Run the chain manually a few times before setting it to active with a schedule.
Document input/output schemas	Define schemas so others (and future you) understand the chain’s data flow.
Monitor run history	Check the Runs page regularly to catch failures early.
Use IF/ELSE for conditional logic	Instead of creating separate chains for different scenarios, use IF/ELSE blocks within one chain.