Every workflow in Evo Workflow Automation starts with a trigger. The trigger is the event that sets the workflow in motion - nothing runs until the trigger fires. Choosing the right trigger is the most important decision when you start building, because it determines how the workflow is started, what data it receives, and whether it sends a response back to the caller.

⚠️ Important: Evo Workflow Automation is not part of the Evo Standard offering. Contact your Access account manager to find out more.

Triggers at a glance

Trigger	Fires when	Best for
Manual	You select Run in the editor.	Testing and one-off jobs.
Schedule	A set schedule is due.	Recurring background work, such as daily reports or hourly checks.
Webhook	An external system sends a request to the workflow's URL.	Anything pushed in from outside Evo, such as forms, billing systems, or custom integrations.
Chat	A user sends a message into a chat surface linked to the workflow.	Conversational workflows that run across multiple turns.
Form	A user submits a form rendered by the workflow.	Simple data collection without a separate form service.
Workflow	Another workflow calls this one directly.	Reusable sub-workflows shared across multiple parent workflows.
Error	Another workflow in your organisation throws an error.	Centralised error handling and notifications.
Polling	A periodic check finds new items in a connected service.	Watching a mailbox, Teams channel, or task list that does not support webhooks.

Manual

The Manual trigger is the simplest option. The workflow only runs when you open the editor and select Run - nothing fires automatically.

Use the Manual trigger when:

You are testing a workflow you are building.
The workflow is a one-off task that you want to run by hand whenever you need it.
You do not want anything to fire on a schedule or in response to an external event.

📌 Note: A workflow with a Manual trigger never runs on its own. It only runs when someone opens the editor and selects Run.

Schedule

The Schedule trigger fires the workflow automatically at a time and frequency you define. You set the schedule when you configure the trigger node - for example, every hour, every day at 9am, or every Monday morning.

Use the Schedule trigger when:

The workflow needs to run on a recurring basis.
There is no external event to kick it off — the schedule itself is the trigger.
The workflow runs in the background and no caller is waiting for a result.

📌 Note: Scheduled workflows run as the workflow owner. If the owner's account is deactivated, scheduled runs will stop. For workflows that need to run reliably over time, make sure the workflow is owned by someone who will remain active in the system.

Webhook

The Webhook trigger exposes the workflow as a web address. When an external system sends a request to that address, the workflow fires. Each Webhook trigger gets its own unique URL, and you can also set a custom path to make it easier to identify.

Use the Webhook trigger when:

Something outside Evo needs to send data into a workflow — for example, a web form, a customer relationship management (CRM) system, a billing platform, or a custom integration.
You want to trigger the workflow from a link, such as an approval button in an email.
You need to expose the workflow to any system that can make a web request.

Authentication options

You can control who is allowed to call the webhook by setting an authentication method on the trigger node:

Authentication option	How it works
None	Anyone with the URL can trigger the workflow. Suitable for internal or low-risk use only.
Basic auth	The caller must provide a username and password.
Header auth	The caller must include a specific value in the request header.
JWT	The caller must provide a valid JSON Web Token (JWT).

Response modes

You can also control what the webhook returns to the caller:

Response mode	What happens	When to use it
Immediately	The workflow accepts the request straight away and runs in the background. The caller receives a confirmation but not the workflow's output.	When the caller does not need to wait for the result.
When last node finishes	The caller waits while the workflow runs and receives the final output when it completes.	When the caller needs the result of the workflow.
Using a Respond to Trigger node	The workflow controls exactly what is sent back and when, using a dedicated node placed anywhere in the workflow.	When you need full control over the response - for example, a specific message, status, or format.

Chat

The Chat trigger fires when a user sends a message into a chat surface linked to the workflow. Unlike most triggers, the Chat trigger maintains conversation context across multiple messages - the workflow remembers what was said earlier in the same conversation.

Use the Chat trigger when:

The workflow is a conversation rather than a single task — for example, a question-and-answer assistant or a guided process that spans several exchanges.
You want to pair the workflow with an AI node that can respond intelligently based on the conversation so far.

📌 Note: The chat surface is available within Evo Workflow Automation. You can also embed it in other locations using the embed code provided on the trigger node.

Form

The Form trigger renders a form that users can fill in and submit. When the form is submitted, the workflow fires and receives the form data. You configure the form fields, labels, and validation directly on the trigger node - no separate form service is needed.

Use the Form trigger when:

You need a straightforward way to collect information from users before a workflow runs.
The person submitting the form does not need an account in your system.
The downstream process is workflow-shaped — for example, validate the submission, look something up, route it, and send a notification.

🤓 Tip: For more complex or customer-facing forms, consider using a dedicated form tool and connecting it to Workflow Automation using a Webhook trigger instead.

Workflow trigger

The Workflow trigger fires when another workflow in your organisation calls this one directly. It allows you to package a set of steps as a reusable sub-workflow that other workflows can call whenever they need it.

Use the Workflow trigger when:

The same logic appears in several different workflows and you want to maintain it in one place.
You want to fix a bug or make an improvement once and have it apply everywhere the sub-workflow is used.

Error trigger

The Error trigger fires when any other workflow in your organisation throws an error during execution. The error workflow receives details about what went wrong, including which workflow failed and what the error was.

Use the Error trigger when:

You want a single workflow to handle all error notifications — for example, sending a message to a Teams channel or logging the failure to a data table.
You do not want to add error-handling steps inside every workflow you build.

📌 Note: One Error trigger workflow can cover your entire organisation's workflows. You do not need to add error handling to each workflow individually.

Polling triggers

Some services do not support webhooks - they cannot push data to Workflow Automation when something changes. For these services, Workflow Automation checks for new items on a regular schedule and fires the workflow when it finds something new.

Polling triggers keep track of what they have already seen, so each new item only fires the workflow once.

Polling trigger	What it watches
Outlook (polling)	Your mailbox for new emails.
Microsoft Teams (polling)	A Teams channel for new messages.
Asana (polling)	Asana for new or updated tasks.
Polling (generic)	Any web address or connected service that does not have a dedicated polling trigger.

Use a polling trigger when:

The service you need to watch does not offer webhooks.
A short delay between the event happening and the workflow firing is acceptable.

⚠️ Important: On the first run, a polling trigger will look back through recent history to find items it has not seen before. If you have a large volume of existing items, this first run may fire the workflow many times. Check the lookback setting on the trigger node before you deploy for the first time.

Choosing the right trigger

Use the following as a guide when deciding which trigger to use:

The work runs on a clock — use Schedule.
An external system can send a request to a URL — use Webhook.
A user types into a conversation — use Chat.
A user fills in a form — use Form.
Another workflow calls this one — use Workflow trigger.
You need to handle failures from other workflows — use Error trigger.
You need to watch Outlook, Teams, or Asana — use the relevant polling trigger.
You need to watch something else that does not push — use Polling (generic).
None of the above and you will run it yourself — use Manual.