Manage Triggers

Monitor and control event-based triggers that automatically start process instances. Manage Triggers provides a centralized interface to view, activate, and deactivate triggers configured in your project builds.

Overview

The Manage Triggers feature provides a centralized interface for monitoring and controlling event-based triggers that automatically start process instances. Triggers connect external events (such as email arrivals, message events, or other data sources) to your process definitions, enabling event-driven automation.

Trigger Types

Currently supported trigger types include:

• Email Triggers: Automatically start processes when emails arrive in monitored mailboxes
• Additional trigger types may be available based on your FlowX.AI version

Accessing manage triggers

Navigate to Runtime Settings → Manage Triggers from your project’s Runtime view to access the triggers management interface.

You must have appropriate runtime permissions to view and manage triggers. See Access Management for details.

Trigger list

The Manage Triggers interface displays all triggers configured in your active build. Each trigger appears as a row in the table with the following information:

Column	Description
State	Current status: Active (monitoring enabled) or Inactive (monitoring paused)
Trigger Type	The type of trigger (for example, “Email Trigger”)
Event Name	The name of the trigger data source or event configuration
Location	Project and build information where the trigger is configured

Empty state

When no triggers are configured for your project, the interface displays an empty state message: “There are no triggers on this project yet.”

Triggers appear in this list once:

1. ✅ A trigger data source is created (for example, Email Trigger in Integration Designer)
2. ✅ The trigger is linked to a Message Start Event node in a process definition
3. ✅ The process is included in a build that is part of the Active Policy

Activating and deactivating triggers

You can control trigger monitoring directly from the Manage Triggers interface:

1. View triggers

   Navigate to Runtime Settings → Manage Triggers to see all available triggers for your active build.

2. Toggle trigger state

   Use the toggle control in the State column to activate or deactivate monitoring:

   • Active: The system monitors for events and creates process instances automatically
   • Inactive: Monitoring is paused; no new process instances are created from this trigger

   

When you change the Active Policy (switch to a different build), triggers retain their previous activation state. If a trigger is removed from the new active build, it will be automatically deactivated.

Trigger activation requirements

For a trigger to appear in Manage Triggers, it must meet all of the following requirements:

1. Trigger data source exists: The trigger must be configured as a data source (for example, Email Trigger in Integration Designer)
2. Linked to process: The trigger must be connected to a Message Start Event node in a process definition
3. In active build: The process containing the trigger must be part of a build that is set as the Active Policy

Triggers are read-only in the Runtime view. To modify trigger configurations (for example, change email server settings, update filters), you must edit the data source in Integration Designer and create a new build.

Use cases

Email-based automation

Automatically start customer support processes when emails arrive in monitored mailboxes. Email Triggers enable event-driven workflows for support ticket creation, document processing, and request handling.

Event-driven processes

Connect external systems to FlowX processes through event triggers. When external events occur (emails, messages, API calls), processes start automatically without manual intervention.

Production control

Pause or resume trigger monitoring in production environments without redeploying builds. This is especially useful for maintenance windows or when troubleshooting issues.

Multi-environment management

Manage trigger states independently across different environments (dev, staging, production) while using the same build configuration.

Monitoring trigger activity

Failed triggers

When triggers fail to process events (for example, email validation errors, connection issues), they appear in the Failed Triggers section.

Navigate to Runtime Settings → Failed Triggers to view:

• Timestamp of the failure
• Trigger type and name
• Cause type (for example, “File type not permitted,” “File size exceeded”)
• Context information (for example, sender email, file details)

Failed Triggers Documentation

See the Failed Process Start documentation for details on handling trigger failures.

Best practices

Test before activation

Always test triggers in development environments before activating them in production. Verify that process instances start correctly and handle edge cases.

Monitor failed triggers

Regularly check the Failed Triggers section to identify and resolve issues. Common causes include file size limits, connection problems, and validation errors.

Use descriptive names

Give triggers descriptive names in Integration Designer to make them easily identifiable in the Manage Triggers list.

Document trigger behavior

Document which processes are triggered by each trigger and under what conditions. This helps with troubleshooting and maintenance.

Related resources

Email Trigger

Learn how to configure Email Triggers in Integration Designer and connect them to Message Start Events.

Message Start Events

Understand how Message Start Events work and how to configure them in process definitions.

Active Policy

Learn how to set the Active Policy to control which build’s triggers are available for management.

Failed Process Start

Troubleshoot trigger failures and understand error handling for failed process starts.