Integrating SharePoint with Power Automate: Patterns & Pitfalls

Power Automate replaced SharePoint Designer workflows, and for most "when something happens in a list, do something" automation it's the right tool. But the easy on-ramp hides traps that bite in production: flows that trigger themselves into infinite loops, race conditions on concurrent edits, and the wall you hit when the standard SharePoint actions can't do what you need. Here's how to build flows that survive contact with real users.

Triggers, and why they fire too often

The SharePoint connector offers When an item is created, When an item is created or modified, and When an item is deleted. The "created or modified" trigger is the workhorse — and the source of the most pain, because it fires on every change, including changes your own flow makes.

The infinite loop. A flow triggered on "modified" that updates the same item re-triggers itself, which updates the item, which re-triggers… Power Automate has loop-protection that eventually halts a flow that triggers itself in a tight cycle, but you should never rely on it. Design the loop out.

Breaking the loop with a trigger condition

The clean fix is a trigger condition — an expression evaluated before the flow runs; if it's false, the flow doesn't trigger at all (and doesn't consume a run). A common pattern: add a hidden "ProcessedByFlow" flag, set it when you process, and only trigger when it's not set:

@equals(triggerOutputs()?['body/ProcessedByFlow'], false)

Your flow does its work, then updates the item setting ProcessedByFlow = true. That update re-fires the trigger, but the condition is now false, so the flow stops. One controlled extra evaluation instead of an endless cascade. Another frequent condition: only run when a specific column changed or has a specific value.

Concurrency: the silent data race

By default the automated SharePoint trigger processes items with a degree of parallelism. If two flow runs touch related data, or order matters, you can get races. The concurrency control setting (trigger → Settings) lets you cap the Degree of Parallelism — set it to 1 to force strictly sequential processing.

Setting concurrency to 1 trades throughput for correctness. For flows that must process items in order, or that update shared aggregates, it prevents lost updates. For independent, high-volume items, leave it parallel. Decide deliberately — the default is "parallel," which is wrong for ordered workloads.

When standard actions aren't enough: Send an HTTP request to SharePoint

The pre-built actions cover common operations, but plenty of things — setting field defaults, working with content types, breaking permission inheritance, batch operations, reading properties the connector doesn't expose — require raw REST. The Send an HTTP request to SharePoint action calls the SharePoint REST API inside the flow, already authenticated as the connection:

Method: POST
Uri:    _api/web/lists/getbytitle('Contracts')/items(@{triggerOutputs()?['body/ID']})/breakroleinheritance(copyRoleAssignments=false,clearSubscopes=true)
Headers:
  Accept: application/json;odata=nometadata
  Content-Type: application/json;odata=verbose

Because the URI is relative to the site and the action handles auth, you get the full power of the REST API — including the $batch endpoint for bulk operations — without leaving the flow. This single action is what turns Power Automate from "low-code toy" into a serious SharePoint automation tool.

Example: grant a user permission via REST

Method: POST
Uri:    _api/web/lists/getbytitle('Contracts')/items(@{variables('ItemId')})/roleassignments/addroleassignment(principalid=@{variables('PrincipalId')},roledefid=1073741826)
Headers:
  Accept: application/json;odata=nometadata

roledefid 1073741826 = Read. Resolve principal IDs via _api/web/siteusers or ensureuser.

Reliability patterns

Configure retry & timeout on actions that call external systems (Settings → Retry Policy). Transient failures are normal; a sensible exponential retry saves a run.
Use Scope + Configure run after to build try/catch/finally: a Try scope, a Catch scope set to run only "has failed," and a Finally scope that always runs.
Add a "Terminate" action with a meaningful status and message in your catch scope so failures are visible, not silent.
Filter early. Trigger conditions are cheaper and cleaner than a Condition action at the top of the flow — they avoid consuming a run entirely.

Power Automate vs Azure Functions / Logic Apps

Signal	Lean towards
Citizen-developer maintained, low volume	Power Automate
High volume, complex logic, strict SLAs	Azure Functions (webhooks)
Need source control, CI/CD, unit tests	Functions / Logic Apps (code)
Quick approvals, notifications, simple updates	Power Automate

Power Automate is the right first reach for most SharePoint automation — fast to build and accessible to the business. The difference between a flow that quietly corrupts data and one that runs for years is exactly the discipline above: trigger conditions to stop loops, concurrency control for ordering, the HTTP action when you outgrow the connector, and proper error scopes. Build those in from the start.

Dhaval Shah

Cloud Solution Architect — 18+ years across SharePoint, Microsoft 365, and Azure AI.

Back to Blog