Understanding Triggers and Actions
Every Conduitly workflow is built from two things: a trigger and at least one action. This article explains what each one does, how they work together, and what to keep in mind when building your first workflow.
What a trigger does
A trigger is the event that starts a workflow. Conduitly watches your trigger app continuously and runs the workflow automatically every time that event occurs.
For example:
- A new employee is added in EmCentrix → trigger fires
- A new row is added to a Google Sheet → trigger fires
- A form is submitted → trigger fires
Every workflow has exactly one trigger. You choose the trigger app and the specific event within that app when you build the workflow.
How triggers check for new data
Most triggers work by polling. Conduitly checks your trigger app at a regular interval to look for new events. How often it checks depends on your plan and trigger settings:
- Individual plan: every 10 minutes at minimum
- Pro and Team plans: every 2 minutes at minimum
- Business plan: every 1 minute at minimum
This interval is called the minimum interval. It means there can be a short delay between when something happens in your trigger app and when the workflow runs, depending on the trigger type and your plan.
Some workflows use webhooks instead of polling. Webhook-based triggers respond in real time, without waiting for the next polling interval.
What an action does
An action is a task Conduitly performs after the trigger fires. It's what happens in the destination app, the result the workflow produces.
For example:
- Trigger fires → Create a record in QuickBooks Desktop
- Trigger fires → Add a row to a Google Sheet
- Trigger fires → Send a Slack message
- Trigger fires → Create a task in Asana
A single workflow can include multiple actions. Each action runs in sequence, in the order you configure them. If a workflow has three actions, all three run every time the trigger fires, unless you set up an if condition or branching workflow.
How tasks are counted
Each time an action step runs successfully, it counts as one task against your plan's monthly limit. If your workflow has two action steps and runs ten times, that's 20 tasks.
If you reach your task limit, workflows pause automatically until your next billing cycle unless you choose to upgrade your plan or enable task overages for an extra charge. You can check your current usage from the plan indicator at the bottom of the sidebar.
See Understanding your plan and task limits for more detail.
Triggers and actions work together
Here's the full picture of how data moves through a workflow:
- Something happens in your trigger app (the trigger event)
- Conduitly detects it and starts the workflow
- Data from the trigger is passed through Conduitly
- Each action step runs in sequence, using that data to do something in another app

The connection between trigger data and action fields is set up in the Mapping step during workflow configuration. Mapping is how you tell Conduitly: "Take this field from the trigger app and put it in this field in the action app." See Mapping fields between systems for a full walkthrough.
A practical example
A PEO wants to automatically sync new employee records from PrismHR into QuickBooks Desktop when HR onboards someone.
| Step | App | Event |
|---|---|---|
| Trigger | PrismHR | New Employee Created |
| Action | QuickBooks Desktop | Create Employee Record |
Every time a new employee is added in PrismHR, Conduitly detects it, takes the employee data, and creates the corresponding record in QuickBooks Desktop automatically, with no manual export or re-entry required.
What to keep in mind
- One trigger per workflow. If you need to respond to events from two different apps, build two separate workflows.
- Multiple actions are allowed. A single trigger can kick off as many action steps as you need, syncing to multiple systems at once.
- Actions run in order. If an earlier action fails, later actions in the same run may not execute. Check Activities to see what ran and what didn't.
- Triggers don't run retroactively. When you publish a workflow, it starts watching for new trigger events from that point forward. It won't process events that happened before the workflow was published.
Related articles
- Build your first workflow
- Mapping fields between systems
- Testing a workflow before publishing
- Understanding your plan and task limits