Trigger vs Action in Power Automate
In Power Automate, a trigger is the event that starts a flow, such as a new email arriving, a file being added to SharePoint, or a scheduled time being reached. An action is a step the flow performs after it starts, such as sending a notification, updating a record, or calling an API. Every flow has exactly one trigger and can have any number of actions running in sequence or in parallel after it.
A trigger starts a Power Automate flow when something happens, while an action carries out a step within the flow after it has started.
Two different jobs in one flow
Every flow in Power Automate is built from the same two categories of building blocks: exactly one trigger, and any number of actions that follow it. Understanding the distinction is the first real step toward building reliable automations, because it determines what starts a process versus what that process actually does once it is running.
The trigger answers the question “when should this flow run?” The actions answer the question “what should happen once it does?” Mixing these up, for example expecting a flow to start without any defined trigger, is one of the most common beginner mistakes when building a first flow.
What counts as a trigger
A trigger is always the first step in a flow and defines the condition that sets everything else in motion. Common trigger types include an event happening in a connected app, such as a new email landing in a shared inbox or a new row being added to an Excel table; a scheduled trigger that fires at fixed times, such as every weekday morning; and a manual trigger, started by a person clicking a button in the mobile app, a Teams tab, or an embedded form. A special trigger, “When a HTTP request is received,” turns the flow into a webhook that external systems can call directly; see our guide on setting up a Power Automate webhook for a practical walkthrough.
A flow can only have one trigger. If a process genuinely needs to start from several different events, the usual pattern is building separate flows per trigger that each call a shared child flow containing the common logic, rather than trying to force multiple triggers into a single flow.
What counts as an action
Once a flow has started, actions are the steps that do the actual work: sending an email, creating a file, updating a SharePoint list, posting a Teams message, or calling an external API through an HTTP action. Actions run in the order they appear in the flow, one after another, unless explicitly configured to run in parallel branches. Many actions also support conditional logic, so a step only executes if a specific condition is met, such as only notifying a manager when an invoice exceeds a set amount.
Actions can be grouped into loops using “Apply to each,” which repeats the same set of actions once for every item in a list, such as every row returned from a database query or every attachment in an email. This is what allows a single flow to process a batch of records rather than only a single item at a time.
Putting it together: a practical example
A common example combines both concepts clearly: the trigger is a new invoice email arriving in a shared mailbox, and the actions that follow extract the attachment, save it to SharePoint, read key fields with AI Builder, and send an approval request if the amount exceeds a threshold. For a full walkthrough of a scenario like this, see automating invoice processing with Power Automate. The trigger is what makes the flow event-driven rather than something someone has to remember to run manually, while the chain of actions is what turns a single event into a complete, repeatable business process.
Our tip: When designing a new flow, write down the trigger and the list of actions in plain language before opening Power Automate. It is much faster to spot a missing step or unclear condition on paper than after you have already built half the flow.
Frequently asked questions
Can a Power Automate flow have more than one trigger?
No, a single flow can only have one trigger, which defines how and when it starts. If you need a process to start from multiple different events, such as either a new email or a new SharePoint item, the common approach is building separate flows for each trigger that then call a shared child flow containing the common actions, avoiding duplicated logic.
What are the main types of triggers in Power Automate?
Triggers generally fall into three categories: automated triggers that fire on an event in a connected service, such as a new file in OneDrive or a new row in an Excel table; scheduled triggers that run at fixed intervals, such as daily or weekly; and manual or instant triggers, which start when a person clicks a button, either in the Power Automate app, Teams, or a form. The 'When a HTTP request is received' trigger is a special case that turns a flow into a webhook endpoint, letting external systems start it via an HTTP call.
Can actions run conditionally in a flow?
Yes, Power Automate supports condition actions ('if this, then that') and switch actions for branching logic, so certain actions only run when specific criteria are met, such as an invoice amount exceeding a threshold before requiring manager approval. Actions can also be grouped inside 'Apply to each' loops to process each item in a list, such as sending an email for every row in a table.
What happens if an action fails inside a flow?
By default, if an action fails, the flow stops running and is marked as failed unless error handling has been configured. Power Automate supports configuring a 'Run after' setting on subsequent actions to control what happens on failure, timeout, or skip, and it is common to add a parallel branch that sends an alert or logs the error whenever a critical action fails, so problems are caught quickly rather than discovered days later.