Automated cloud flow

What is an automated cloud flow?

An automated cloud flow is a cloud flow that starts on its own when something happens in a connected service. A new row in Microsoft Dataverse, an incoming email, a file added to a folder, or a submitted form can each begin a run without anyone pressing a button.

The trigger watches for or receives that event and hands its data to the first actions. In Power Automate, this makes the automated type the right fit for work that has to follow reliably from a change in a system.

How the event trigger works

Some triggers receive a notification the moment the source publishes an event. Others poll the source on an interval, so a run may start a minute or a few minutes after the change rather than instantly. Trigger data usually carries an ID and a handful of properties from the changed record, so read critical fields back from the source if the current state is what matters, since the record can move on between the event and the run.

A trigger condition keeps irrelevant events from spinning up a full run. A flow that acts on approved requests, for instance, need not fire every time someone edits an unrelated note.

A worked example

When a new support case lands in Dataverse, an automated cloud flow reads the record, works out the right service team, creates a task, and emails the customer an acknowledgement with the case number. It stores a unique reference to that task, so if the same event arrives twice it finds the existing task instead of making a duplicate. If the email fails after the task exists, only that step is retried, and a failure path logs the case ID, step, and error code for the team.

Automated, instant or scheduled?

Reach for an automated cloud flow when a system event owns the start moment. When a person or a calling app decides when to run, an instant cloud flow fits better; for periodic work with no single triggering event, use a scheduled cloud flow.

Design actions to be idempotent when a source can deliver the same event more than once, and use a business key to spot duplicates. Separate a temporary error, which a retry policy can handle, from invalid business data, which needs correction rather than endless retries. Watch expected volume too, not only failures: a flow with no errors can still have gone quiet because its trigger stopped receiving events.