Cloud flow

What is a cloud flow?

A cloud flow is a workflow in Microsoft Power Automate that connects online services and data sources to each other. It starts with a trigger and then runs a series of actions. Microsoft runs the flow in the cloud, so no one's computer has to stay switched on for it to work.

A simple one might start when a new form response arrives, create a record, request an approval, and email the result back to the person who asked. Connectors turn the features of services like Forms, Dataverse, Teams, and Outlook into triggers and actions you can drop into the flow. Cloud flows suit steps that go through APIs and cloud services. When a system can only be driven through its buttons and fields, a desktop flow can cover that part instead.

Triggers, actions and connectors

The trigger decides when a run happens and often supplies the first data. It can react to a new record, an incoming email, an HTTP request, a manual button, or a schedule. Actions do the work after that: they read or write data, send a message, check a condition, wait for an approval, or call another flow. The output of one action becomes input for a later step.

A connector describes how Power Automate talks to a service, while the connection holds the sign-in behind it. That split matters: the connector sets out which operations exist, and the connection decides the identity they run under. Conditions, loops, and parallel branches shape the control flow, but use them with restraint. A flow buried in nested conditions is hard to test and often belongs split into child flows or moved to a different layer of the process.

Three ways a cloud flow starts

Power Automate names cloud flows by how they begin, though the trigger-and-action idea underneath is the same in each. The start type mainly decides who or what picks the moment.

• Automated cloud flow. Reacts to an event, such as a new row in Dataverse or a file added to SharePoint. This fits processes that should begin soon after something changes.

• Instant cloud flow. Runs when a person, app, or another flow asks for it, for example a button that submits the selected record for approval.

• Scheduled cloud flow. Runs on a schedule. It might gather open tasks every working morning or build a check dataset once a month.

Two worked examples

Document approval

When a contract appears in a SharePoint folder, the flow reads its metadata and sends an approval request. On approval it moves the file and records the date and the approver; on rejection it asks for a reason and tells the author. The point is not that a green designer proves the process is right, but that you have decided which source leads, what happens on duplicate events, and who handles exceptions.

Chasing open tasks

Each morning a scheduled flow finds tasks whose due date is near, groups them by owner, and sends one message each. A separate error branch records failed connector calls, so an administrator knows when a reminder might have gone out incomplete.

Cloud flow versus desktop flow

A cloud flow talks to services through connectors and APIs, which is generally steadier than driving a user interface. It can run in the background and needs no interactive Windows session. A desktop flow automates websites and desktop programs through their on-screen elements, which helps with older software that offers no suitable API, but makes the automation more sensitive to screen changes and pop-ups. The two work well together: a cloud flow can receive a case, start a desktop flow on a managed machine, and write the result back to Dataverse. Keep the on-screen part as small as you can.

Reliability and management

Connectors have limits, timeouts, and occasional transient errors. Set retries only on actions that are safe to repeat. A blind retry while creating a payment or an order can produce a duplicate, so lean on a unique business key or an idempotent design. Use scopes to separate the main path from the error path, and log the run, the relevant input, and any error without recording passwords or unnecessary personal data. Send alerts to a managed channel, not only to whoever built the flow.

Put business flows in solutions, use connection references and environment variables, and move changes through separate environments. Check ownership and connections when people change roles. Track run duration, failure rate, and overdue runs, because a valid, saved flow is not the same as a reliable one. Reliability shows up in how a flow runs, recovers, and lands the right business result.