Triggers and Actions
Understand what starts a workflow and what it does next.
Triggers start workflows. Actions perform the work.
Every workflow needs one trigger and at least one useful step after it. The trigger answers “when should this start?” Actions answer “what should Agiled do next?”
Choose triggers and actions around one clear business outcome. If the workflow tries to solve several unrelated processes, it becomes harder to test and debug.
Triggers
Choose a trigger that matches a meaningful business event, such as a form submission, ticket creation, deal update, invoice event, project event, or scheduled run.
Common trigger types include:
- A CRM event, such as a form submission, contact update, deal change, or ticket activity.
- A finance event, such as an invoice, payment, estimate, or billing milestone.
- A productivity event, such as a project or task change.
- A manual run for workflows that a user starts intentionally.
- A scheduled run for recurring checks and reminders.
- A webhook run when an external system starts the workflow.
When configuring a trigger, fill every required field in the configuration panel. The builder shows warnings when required trigger fields are missing or a saved value no longer matches the expected type.
Actions
Actions can create or update records, send notifications, create tasks, connect files, update CRM, or perform other supported business operations.
Action configuration depends on the selected action. Use the fields in the right-side configuration panel to choose owners, statuses, record links, message copy, due dates, and any module-specific settings.
Actions can use trigger data and records created by earlier steps. For example, a form submission trigger can create a contact, and a later action can use that created contact when creating a task or ticket.
Keep Actions Focused
Avoid building a large workflow before testing the first action. Smaller workflows are easier to debug and safer to change.
Build in this order:
- Add the trigger.
- Add one action.
- Save and test with safe data.
- Review the run detail and created records.
- Add conditions, delays, or more actions only after the basic path works.
Configuration Warnings
Fix warnings before publishing. Common warnings mean a required field is empty, a selected record is no longer available, or a saved value has the wrong type. Warnings are not just cosmetic; they usually explain why a workflow would fail or create incomplete work.
Use Data From Earlier Steps Carefully
When an action uses data from the trigger or a previous action, verify that the data exists for every record that can enter the workflow. A form submission may have an email, but a manual run may not. A created contact may exist only when a previous step succeeds.
If later actions depend on earlier output, test both the successful path and a record that should stop before those actions run.
Pre-Publish Review
Before publishing:
- Confirm the trigger is specific enough.
- Confirm each action has required fields.
- Confirm customer-facing messages have safe recipients and copy.
- Simulate the workflow.
- Run one safe test record.
- Review run detail before enabling broader use.
Choosing the Right Action
Choose the most specific action that matches the business result. Creating a task is useful for human follow-up. Creating a ticket is better for customer support intake. Updating a CRM record is better when the workflow is changing pipeline state. Sending a notification is better when the workflow should alert a teammate without changing customer data.