Cloud flow types and triggers

What it does

Every cloud flow starts with exactly one trigger, and the trigger you pick is what makes the flow automated, instant or scheduled. Automated flows fire on an event in a connected service, instant flows are started by a person or a calling app, scheduled flows run on a recurrence.

Key facts

One trigger per flow. Changing the trigger type after the fact means rebuilding the flow, so the choice is effectively permanent.
Trigger conditions are expressions evaluated before a run starts. If the condition is false, no run happens and nothing appears in run history.
Because a failed trigger condition produces no run, it doesn't consume an action against your request limits — filtering with a Condition action inside the flow does.
Every trigger condition must start with @. Multiple conditions are ANDed by default; use @or(...) if you want either.
The Recurrence trigger supports intervals up to a maximum of 500 days.
Polling triggers check on an interval and pick up changes since the last check. Webhook triggers are pushed by the service. The card looks the same in the designer, so read the connector reference if latency matters.
A flow that isn't triggered at all within 90 days may be switched off. Flows owned by users with premium or assigned capacity licences are exempt, and owners get 30 days' warning.

When to use / skip

Pick the trigger first and the rest of the design follows. Automated is the default answer for anything reacting to data changes. Instant is for human-initiated work and for anything called from Power Apps, Teams or a parent flow. Scheduled is for batch work and reconciliation, and it's usually the wrong answer for anything a user is waiting on. If you find yourself building a scheduled flow that polls for changes a connector already has a trigger for, stop and use the trigger.

Configuration decisions

Which trigger type the business process actually needs, given the trigger cannot be swapped later.
Whether a trigger condition can do the filtering instead of an in-flow Condition, which cuts both runs and request consumption.
For SharePoint and Dataverse triggers, which columns or change scope should fire the flow, so edits to unrelated fields don't wake it up.
For scheduled flows, the recurrence interval, time zone and what happens if a run overruns the next scheduled slot.
Whether the flow lives in a solution, which affects trigger behaviour on import and whether drafts and versioning are available.

Gotchas

A flow updating the same list it triggers on will retrigger itself. You need a trigger condition or a marker column to break the loop, and it's usually discovered in production.
Trigger conditions are typed into a plain text box with no validation and no IntelliSense. A syntax error means the flow silently never runs, which looks identical to "no data changed".
Dataverse triggers with an overly broad filter fire on system-generated updates you didn't know existed, and the run count goes through the roof.
Instant flows called from Power Apps must use the PowerAppsV2 trigger. The v1 trigger won't open in the new designer at all.

Consultant notes

Get the client to describe the business event in their own words before you choose a trigger. "When the invoice is approved" and "when the record changes" are very different flows.
Trigger conditions are the cheapest performance fix on the platform and the easiest to sell — fewer runs, lower request consumption, less noise in run history.
Warn clients that unused flows can be switched off on the 90-day rule. Seasonal processes like year-end reporting are the usual casualty.
Document trigger conditions somewhere outside the flow. They're invisible on the canvas and the next person to maintain the flow will not find them.

Worth a look after the next release wave, or the first time someone asks why a flow "randomly stopped running".