Run a Power Automate Flow from a SharePoint List Button

A SharePoint list can show a button on every row that launches a Power Automate flow for that item. You do not need a Power Apps form or an SPFx extension for the basic pattern.

The supported pieces are:

1. An instant cloud flow using SharePoint's For a selected item trigger.
2. A normal list column formatted with SharePoint JSON.
3. A customRowAction whose action is executeFlow and whose id is copied from Power Automate.

The button makes a flow easier to find. It does not bypass permissions, connections or the confirmation panel.

Fact-checked against Microsoft Learn on 7 August 2026.

What the user experience looks like

The list shows an action such as Send to manager beside each item. The user selects it, the Power Automate launch panel opens, and the flow runs against that row.

Microsoft documents a small difference:

• For a solution-aware flow, the launch panel opens and the user selects Run Flow.
• For a flow that is not solution-aware, Microsoft says the launch panel appears and the flow then runs.

This is an explicit user action, not an unattended trigger. Use it for work such as requesting approval, generating a document, re-running a controlled calculation or escalating the selected record.

Do not use a row button when the process should happen automatically for every qualifying item. In that case, use a created/modified trigger with proper trigger conditions.

Before you build it

You need:

• permission to edit the SharePoint list;
• permission to create and share the flow;
• a list with at least one test item;
• a normal user who can test the finished button; and
• a clear decision about who is allowed to run the action.

Build in a test list or use an action with a reversible result. A button that sends real mail or changes a production record is a poor first test.

1. Create the selected-item flow

From Power Automate, create an Instant cloud flow. Choose the SharePoint trigger For a selected item.

Set the Site Address and List Name. Save the flow before looking for its identifier.

The trigger supplies the selected item's context. Depending on the actions you add, you may need SharePoint's Get item action to retrieve all current column values. Use the item identifier from the trigger rather than searching the list by a non-unique title.

Add a small test action first—for example, compose the item ID or send a message only to yourself. Save and run the flow from the list's normal Power Automate menu before adding the custom button. This separates a flow problem from a formatting problem.

2. Configure run-only access and connections

Open the flow's details and review Run-only users. Add the people or group who should be able to launch it.

For each connector, decide whether the flow uses:

• the connection supplied by the run-only user; or
• a connection already defined in the flow.

That decision changes whose authority the action uses. Do not hide an elevated service connection behind a friendly list button without reviewing what a normal user can make it do.

The user also needs access to the SharePoint list item. A button does not grant access to a record or to downstream systems.

Test with a normal run-only account before rollout. The maker/owner experience proves very little about the audience's connection prompts and permissions.

3. Copy the flow identifier

Do not hand-build the identifier from a URL. Microsoft provides Get flow identifier so you can copy the exact value the list formatter expects.

For a solution-aware flow, Microsoft documents this route:

1. In the SharePoint list, select Flow > See your flows. The current UI may show this under Automate > Power Automate.
2. Switch to the environment that hosts the flow, if required.
3. Open Solutions and select the solution.
4. Filter for cloud flows and open the flow.
5. Select Export > Get flow identifier.
6. Copy the identifier.

For a non-solution-aware flow, switch to the correct environment, open the flow, then select Export > Get flow identifier and copy the value.

Microsoft's current JSON example uses a GUID. Whatever Power Automate gives you, paste it unchanged into actionParams. Do not recreate the old article's v1/environment/flow string by hand.

4. Add an Action column

In the SharePoint list, add a Single line of text column called Action. The stored text is not important because JSON formatting will render the button.

Using a separate action column is easier to understand and support than disguising the button inside a business-data field.

Open the Action column menu, choose Column settings > Format this column, then open Advanced mode.

5. Paste the button JSON

This is a close adaptation of Microsoft's current sample. Replace the example GUID with the exact identifier you copied.

{
  "$schema": "https://developer.microsoft.com/json-schemas/sp/v2/column-formatting.schema.json",
  "elmType": "button",
  "customRowAction": {
    "action": "executeFlow",
    "actionParams": "{\"id\": \"edf627d9-20f4-45ba-8bc9-4494bf2ff1be\", \"headerText\": \"Send this item to the manager\", \"runFlowButtonText\": \"Run flow\"}"
  },
  "attributes": {
    "class": "ms-fontColor-themePrimary ms-fontColor-themeDarker--hover",
    "title": "Run the manager approval flow"
  },
  "style": {
    "border": "none",
    "background-color": "transparent",
    "cursor": "pointer"
  },
  "children": [
    {
      "elmType": "span",
      "attributes": {
        "iconName": "Flow"
      },
      "style": {
        "padding-right": "6px"
      }
    },
    {
      "elmType": "span",
      "txtContent": "Send to manager"
    }
  ]
}

Select Save. Each visible row should now show the action.

The required part is the flow id. Microsoft also documents the optional headerText and runFlowButtonText properties used above.

JSON strings inside actionParams are escaped. Keep the backslashes around the inner quotation marks. If you edit the text, change only the visible values unless you are comfortable validating JSON-within-JSON.

6. Run a normal-user test

Select the button on a test row using the account that will really run it.

Verify:

1. The launch panel names the expected flow.
2. The user is not asked to create an inappropriate connection.
3. The flow receives the selected item's ID.
4. The action affects that item and no other row.
5. The run history identifies the user and result clearly.
6. A second click has a safe outcome.

That last test matters. People double-click, retry after a slow response and reopen tabs. A flow that creates duplicate tasks or sends the same approval twice needs an idempotency guard in the flow itself.

Make the action safe to repeat

The button cannot know whether the business action already happened. Add that logic to the flow.

A common pattern is:

1. Get the selected item.
2. Check a status or processed flag.
3. If it is already complete, terminate successfully with a clear message.
4. Perform the action.
5. Update the item with the result, timestamp and run identifier.

If two people can launch the same row concurrently, a simple Boolean check may still race. For consequential processes, use the control or data store that can enforce the uniqueness you need.

Show the button only when it is valid

SharePoint formatting can refer to other fields, so you can hide an action for completed items. For example, add a display rule to the button's style:

"display": "=if([$Status] == 'Ready for approval', 'inline-flex', 'none')"

Status must be the field's internal name. If the column has spaces or was renamed, inspect its internal name rather than guessing.

Conditional display improves the interface; it is not security. The flow must still validate status and permission because a user may invoke it through another surface or while the item changes.

Common problems

The button appears but nothing useful runs

Re-copy the value from Export > Get flow identifier and confirm the list and flow are in the environment you intended. Then test the flow from SharePoint's normal flow menu.

The user sees a connection or permission error

Review run-only users, connector connection settings and access to every downstream resource. Do not solve this by sharing the flow or site with everyone.

The flow runs against the wrong item

Use the selected item's identifier from the trigger. Avoid finding an item by Title, because Title is not guaranteed to be unique.

The JSON editor rejects the formatting

Validate the outer JSON and preserve the escaped quotation marks inside actionParams. Start from Microsoft's sample, change only the flow ID and labels, then add conditional display after the basic button works.

The button is visible for items that should be locked

Add a display condition for usability and repeat the status check inside the flow for enforcement.

A click creates duplicates

Treat the click as a request, not proof that processing has not happened. Re-read the item, check an explicit processed state and make repeat runs safe.

When a list button is the wrong design

Use a custom Power Apps form when the user must enter or validate several values before starting. Use an automatic trigger when every qualifying item should be processed without a person's click. Use a command-set extension only when the requirement genuinely needs custom code and central deployment.

For a more involved Power Apps example, see the Power Apps time-tracker build. For reusable Power Automate construction, use the copy and paste actions guide.

Build flows that survive real users

The Power Automate Builders Space covers the maintainability, permissions and repeat-run questions that sit behind a good demo.

Microsoft sources used

• Advanced SharePoint formatting: create a button to launch a flow
• SharePoint formatting syntax: customRowAction
• SharePoint connector reference

Source boundary: Microsoft documents executeFlow, the identifier route and the launch-panel behaviour. The JSON above adapts Microsoft's sample. Connection prompts, environment policy and user permissions depend on your tenant and flow, so verify with a normal run-only account.