Power Automate action

What is a Power Automate action?

An action is a step that does work inside a Power Automate flow. Once the trigger has started a run, actions get data, change a record, send a message, create a file, or call another flow. A flow is a chain of actions, and the order they run in is the process.

Actions take inputs, such as a record ID or an email address, and most hand back output. A later action can pick up that output as dynamic content, so values travel from step to step.

Not every action talks to an outside service. Power Automate also has built-in steps for conditions, loops, variables, data operations, and delays.

Connector actions and built-in actions

A connector action calls an operation on a connected service: get a Dataverse row, post a Teams message, create a SharePoint file. The connector describes the operation, and the connection supplies the identity and sign-in behind it. Inside a Power Platform solution the flow can point at that connection through a connection reference, and when no ready-made connector fits a service, a custom connector can wrap its API.

A built-in action handles control flow or data inside the flow itself. A Condition picks a branch, Apply to each walks through a collection, and Compose holds or shapes a value without touching an external service.

Even a connector action depends in the end on the service's API and its limits. A successful call means the service accepted the request according to its own contract. For anything that matters, check the real business result rather than trusting the response code alone.

Inputs, outputs, and expressions

The designer shows required and optional input fields for each action. A value can be fixed, come from the trigger, be handed over by an earlier action, or be worked out with an expression.

Output has a technical structure of fields, statuses, and sometimes headers. Dynamic content makes much of that readable in the designer. When the output is more involved JSON, a Parse JSON step can make the schema explicit so later steps reference the fields cleanly.

Handle null, empty text, and missing fields with care. An expression that always finds a value in your test data can still fail on a real run. Validate the input before an action does something you cannot undo.

A worked example

After a trigger for a new form response, a flow first gets the answer details. A Dataverse action then creates a request record, and a Teams action tells the handling team the case number.

The Dataverse action returns the new record ID, and the Teams step uses that ID to build a link. If the record cannot be created, the notification must not pretend the request exists, so the maker puts both actions in one scope. A separate error scope runs through Configure run after when the main scope fails or times out, logs the problem, and alerts the team.

Action versus trigger

The trigger decides what starts a run; actions decide what happens once it has. A trigger can produce output, but it always sits at the start, and an action can only run after the run exists. A single connector often offers both, so read the position: "when a row is added" listens for a change, while "add a row" causes one.

Retries, run after, and idempotence

An action can succeed, fail, be skipped, or time out. Configure run after sets which of those statuses lets the next step run, and scopes help you group the main path, the error path, and the wrap-up so the flow stays readable.

Retry policies help with passing problems like throttling or a brief network drop. Do not blindly retry an action that could duplicate a payment, an order, or a message. Use an idempotency key or check first whether the result already exists.

Log the step name, the business reference, and the error code, but keep passwords and full sensitive payloads out of the logs. Make it clear which failures recover on their own and which need a person.