Power Automate trigger

What is a Power Automate trigger?

A trigger is the event that starts a Power Automate flow. It decides when a new run begins and hands the flow its first piece of data to work with. Every cloud flow has exactly one trigger, followed by the actions that do the actual work.

A trigger can react to something happening, such as a new row in Microsoft Dataverse or an email landing in Outlook. It can also run on a schedule, or wait to be started by hand from a button, an app, an HTTP request, or another flow.

The trigger does not carry out the business task itself. It reports that the starting condition is met and passes along some context. What happens next is up to the actions.

Automated, instant, and scheduled triggers

Power Automate groups triggers into three kinds, and the one you pick sets the shape of the flow.

• Automated triggers fire when an event happens, like a new file in OneDrive or a submitted form. Not every connector offers one.

• Instant triggers start on demand, for example when you tap a button in the mobile app or run the flow from another tool.

• Scheduled triggers run on a recurrence you define, such as every weekday at 8 am or the first of each month.

Polling and webhooks

Behind an event trigger sit two different mechanisms. With a webhook, the source sends an HTTP message to a registered endpoint the moment something changes, so the flow can start shortly after the event.

With polling, the connector checks the source at set intervals and remembers which items it has already seen. The default interval varies by connector and is typically a few minutes, which means a polling trigger adds some delay between the real event and the flow starting.

The designer does not always show which mechanism a given trigger uses. Base any timing promises on the connector's documentation, and test how it behaves during spikes, outages, and quick back-to-back changes.

Trigger conditions

A trigger condition rejects events you do not care about before a full run ever starts. Say a flow should only handle approved invoices. Without a condition, it wakes up for all 1,000 invoices even though only 50 are approved. With a condition, it runs 50 times, which keeps the run history clean and cuts the number of platform requests you consume.

A trigger condition is not a substitute for validation inside the flow or at the source. Data can still arrive incomplete, change after the fact, or come in through another process, so check the values that matter once the run is going.

A worked example

An automated flow uses the Dataverse trigger for when a row is added, changed, or deleted. It tracks requests and, through a trigger condition, only starts when the status changes to Submitted.

The trigger hands over the request ID and details of the change. The first action reads the full record, because the row may have changed again between the event and the run. The flow then checks whether an approval already exists for this request.

If the same event arrives twice, that check stops a second approval. If processing fails, an error path saves the request ID and the run reference so someone can pick it up later.

Trigger versus action

A trigger starts a run; an action runs inside it. The trigger for when an email arrives can be followed by actions that get the attachment, create a file, and post a message. A trigger listens or checks, while an action asks for or changes something after the flow is already going.

Some connectors offer a trigger and an action with similar names. On the Dataverse connector, "when a row is added" is a trigger and "add a row" is an action: the first listens for a change, the second causes one. Watch for a loop where an action sets off the very trigger that started the flow.

What to watch out for with Power Automate triggers

Check whether an event is delivered at least once, at most once, or possibly more than once, and design important actions to be idempotent when the connector gives no exactly-once guarantee.

Watch expected volume next to failures. A trigger that stops receiving anything produces no failed runs, so it can fail silently. Compare counts at the source against the runs that actually started, and after a schema change confirm the dynamic fields you rely on still exist.