> ## Documentation Index
> Fetch the complete documentation index at: https://docs.letsflow.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Trigger automations

> Understand how manual, request-driven, scheduled, and event-driven runs start.

## How runs start

An automation can start through these entry points:

| Entry point | What starts the run |
| - | - |
| **Manual** | An authorized person starts a published automation |
| **Request** | Flow matches a requester to a published catalog item |
| **Schedule** | A configured date or recurrence becomes due |
| **Event** | A configured provider or Flow event matches its conditions |
| **Webhook or API** | An authenticated external request starts the published automation |
| **Another automation** | A parent automation starts a child automation |

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](/setup/administration/audit-and-api-access#create-machine-access) 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.

<Steps>
  <Step title="Review the generated automation.">
    Check the team, request filters, Slack destination, and message contents.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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**.
  </Step>

  <Step title="Check the next run.">
    Open **Automations → Triggers** to check the schedule. After it runs, open
    **Automations → Monitoring** and confirm that the message reached Slack.
  </Step>
</Steps>

### 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.

<Steps>
  <Step title="Review the event trigger.">
    Check that it listens for a priority increase and only matches **Urgent**.
  </Step>

  <Step title="Test the message.">
    Use **Simulated** mode to check the generated steps and Slack message.
  </Step>

  <Step title="Publish the automation.">
    Choose the intended team, Slack connection, and **Run as** service account.
  </Step>

  <Step title="Try a controlled request.">
    In **Conversations**, open a test request the service account can read. Raise its priority
    from **Normal** to **Urgent**.
  </Step>

  <Step title="Confirm the outcome.">
    Check for the run in **Automations → Monitoring** and the message in Slack.
  </Step>

  <Step title="Check the filter.">
    Use a second test request to confirm that raising its priority from **Normal** to **High**
    does not send a message.
  </Step>
</Steps>

See [Test and publish](/automations/build/test-and-publish) for test modes and
[Publish and execution scope](/automations/build/publish-and-execution-scope) for connection and
service-account setup.

## Review automated triggers

<Steps>
  <Step title="Open Automations → Triggers." />

  <Step title="Filter by team when needed." />

  <Step title="Review each schedule or event trigger, its automation, next or last activity, and current status." />

  <Step title="Open the automation to change its trigger configuration." />

  <Step title="Check Automations → Monitoring when a trigger reports an error or does not create a run." />
</Steps>

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.

## Related topics

* [Publish and execution scope](/automations/build/publish-and-execution-scope)
* [Inputs and approvals](/automations/build/inputs-and-approvals)
* [Monitor automations](/automations/monitor)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.