Triggers are the starting points of any workflow and are required for the Workflow Engine to run.
Core concept
A trigger defines when a workflow should start. When the configured conditions are met, such as an incoming request on a channel or a scheduled event, the workflow starts and the connected jobs are executed sequentially.
Triggers commonly represent events such as:
- An incoming webhook or API request
- A scheduled import
- A manual or test execution
Triggers and channels
Channels are the entry points into the Bosbec platform. They define how traffic enters Bosbec, while triggers filter that traffic and decide whether a workflow should start.
A channel can be kept relatively open, acting like an API that an external system calls, while triggers narrow this down based on criteria such as path, method, or keyword. This allows several workflows to react differently to traffic on the same channel.
See Channels – Incoming for how channels are configured.
Trigger types
Different trigger types provide different data to the workflow context once they fire:
- Incoming HTTP trigger – creates an HTTP resource from the request.
- Message trigger – makes information about an incoming SMS, email, or app message available.
- Form Answered trigger – saves the form answer to the workflow context.
- Scheduled trigger – starts a workflow automatically at a defined interval, commonly used for recurring imports or syncs.
- Event trigger – reacts to platform events, such as a file being uploaded.
See Working with variables for how to reference the data a trigger makes available.
Best practices
- Keep trigger conditions as narrow as required to avoid unintended workflow executions.
- Use a manual or test execution to verify a workflow before relying on its real trigger.
- When several workflows share a channel, use trigger filtering (path, method, keyword) rather than duplicating channels.