Agiled Docs

A trigger decides when the workflow starts. Every workflow should have exactly one trigger.

Choose the trigger before adding actions. The trigger controls which record data and variables are available to the rest of the workflow.

Add A Trigger

Open the workflow builder.
Open the node palette.
Search or browse trigger categories.
Select the trigger.
Open the trigger configuration panel.
Fill in the required fields.
Save the workflow.

The builder validates required trigger configuration. If a required field is missing, fix the warning before publishing.

Write the workflow purpose in one sentence before choosing a trigger. For example, "When a new lead form is submitted, create a follow-up task for sales." That sentence should name the event that starts the workflow.

If the sentence starts with "whenever anything changes," narrow the process before building automation.

Choose The Right Trigger

Pick the business event that most directly represents the process. For example, use a form submission trigger for lead capture and a deal stage trigger for pipeline automation.

Avoid broad triggers when a narrower event exists. A broad trigger can create extra runs, duplicate messages, or tasks for records that should not enter the process.

Start from the outcome: decide what record should change, who should be notified, or what external system should receive data. Then choose the trigger that represents the earliest reliable moment for that outcome.

Configure Trigger Fields

Depending on the trigger, review:

Module or object type.
Status, stage, form, event, or schedule selection.
Conditions that limit when the workflow starts.
Whether imported records should trigger the workflow.
Whether the trigger should run only for new records or also updates.

Use conditions to keep the trigger narrow. A workflow that should handle one form, one pipeline stage, one status, or one schedule should not run for every record in the module.

Decide whether imported or synced records should start the workflow. Imports can create many records at once, and a broad trigger can send unexpected messages or create duplicate tasks.

Test The Trigger

After configuring the trigger, create or update one safe record that should start the workflow. Then open run history and confirm the workflow started for the expected reason.

Also test one record that should not start the workflow. This catches missing conditions before the workflow runs against real customer data.

Check the variables available in the test run before adding customer-facing messages. If the trigger does not provide the field you need, choose a different trigger or adjust the workflow design.

Keep the test record easy to identify. Clear test data makes it faster to find the run, review variables, and clean up created records afterward.

Common Trigger Mistakes

using record updated when a narrower status or stage trigger exists
forgetting to limit a form trigger to one form
letting imports trigger customer-facing automation without review
using a schedule that runs more often than the team can monitor
publishing before the trigger variables are confirmed in a test run

Trigger Review Checklist

Before publishing:

one trigger is configured
required fields are complete
conditions are narrow enough
imported records are handled intentionally
one positive and one negative test have been run
variables needed by later actions are present

Configure A Trigger