Skip to main content

​
How runs start

An automation can start through these entry points: The published audience, execution team, connection access, and input rules still apply when a trigger fires. The Automations → Triggers page lists scheduled and event-triggered runs. Manual, request, webhook, API, and parent-automation starts do not appear there as managed trigger rows.

​
Run work without a new request

Use these examples as starting points for your own automations. Each needs a published automation, a connected Slack workspace, and a service account with permission to run it. Flow uses this account for scheduled and event-triggered runs.

​
Send a weekday request summary

Goal: help the support team see urgent work at the start of the day. In Automations, select New automation and give Flow a prompt like this:
Every weekday at 9 a.m. in Europe/London, find the IT team’s open, urgent requests in Flow. Post their titles and request numbers to our IT support channel in Slack. If there are none, post “No open urgent requests.”
Replace the team, channel, time, and time zone with your own choices. The schedule starts the check; nobody needs to send Flow a message first.
1

Review the generated automation.

Check the team, request filters, Slack destination, and message contents.
2

Test the result.

Start in Simulated mode. Check examples with matching requests and with no matches. Use Live only when you are ready to send a message to the selected Slack channel.
3

Publish the automation.

Select the Slack connection and the service account under Automated execution → Run as. Confirm the schedule and time zone before selecting Publish automation.
4

Check the next run.

Open Automations → Triggers to check the schedule. After it runs, open Automations → Monitoring and confirm that the message reached Slack.

​
Notify the team when a request becomes urgent

Goal: alert support when a request’s priority rises to Urgent. Create another automation with a prompt like this:
When a request’s priority rises to Urgent in Flow or a connected service desk, post its title and request number to our IT support channel in Slack. Do not change the request.
This example includes priority changes made in Flow and changes received through ticket sync from a connected service desk. Confirm that you want both sources to send messages to the channel. It does not cover requests first created as urgent. A priority change made by another Flow automation does not start this event automation.
1

Review the event trigger.

Check that it listens for a priority increase and only matches Urgent.
2

Test the message.

Use Simulated mode to check the generated steps and Slack message.
3

Publish the automation.

Choose the intended team, Slack connection, and Run as service account.
4

Try a controlled request.

In Conversations, open a test request the service account can read. Raise its priority from Normal to Urgent.
5

Confirm the outcome.

Check for the run in Automations → Monitoring and the message in Slack.
6

Check the filter.

Use a second test request to confirm that raising its priority from Normal to High does not send a message.
See Test and publish for test modes and Publish and execution scope for connection and service-account setup.

​
Review automated triggers

1

Open Automations → Triggers.

2

Filter by team when needed.

3

Review each schedule or event trigger, its automation, next or last activity, and current status.

4

Open the automation to change its trigger configuration.

5

Check Automations → Monitoring when a trigger reports an error or does not create a run.

Schedule and event triggers use the active Run as service account selected during publishing. Flow will not start the run when that identity or a required connection is no longer ready.

​
Before a run can start

​
Check child automations

When an automation waits for another automation, the child needs a compatible publication when that step runs. If you rename, delete, or unpublish the child, the parent reference can fail. The parent stays published. Check the child availability warning in its list menu or Readiness. Restore a compatible child publication, or update the parent reference and publish the parent again. References by ID survive a child rename. References by slug need the matching slug. Availability can depend on the execution team, and some references resolve only when the step runs. Flow checks current permissions when starting a child. A child run that has already started keeps its selected version. Starting the parent alone does not reserve a child version for a later step.

​
Check the run requirements

Check that:
  • The intended revision is published.
  • For manual starts and requests, the person is in the published audience.
  • The automation has a valid execution team.
  • Required inputs are present.
  • Required connections and allowed actions are ready.
  • Scheduled and event runs have an active Run as identity that can start the automation and read the records it uses.