Skip to main content
Card class: Hero • Category: Ecommerce Platform
The count of Power Automate cloud-flow runs that failed in the last 24 hours on the flows linking your storefront to Dynamics 365.

​
At a glance

The number of Power Automate cloud-flow runs that ended in a failed state over the last 24 hours, scoped to the flows that connect commerce triggers to Dynamics 365 Finance & Operations actions: order sync, free-text or sales invoice creation, customer / item master sync, and inventory push. A non-zero count means the bridge between your storefront and your ERP is dropping messages. A spike means either the trigger source is down or the F&O connector is being throttled.
What it countsFailed cloud-flow runs in the trailing 24 hours, limited to the flows tagged as ecom-to-D365 integration. Conceptually count(flow runs WHERE status = Failed AND flow IN ecom-integration set) over the last 24h. These are the flows that carry storefront orders into F&O sales orders, raise free-text / sales invoices, and push inventory and master data between the systems.
Failure scopeOnly terminal failures count. Runs that succeeded after a built-in retry are not failures. Runs still in progress or queued are not yet failures. A run that exhausted its retries and ended Failed is counted once.
Which flowsThe set is the integration flows linking commerce to F&O: order ingestion, invoice creation, customer and item master sync, inventory push. Internal F&O-only flows and unrelated business automations are excluded so the card stays focused on the storefront bridge.
Multi-Company / legal entityWhere flows write into more than one legal entity, all in-scope flows are counted together. The card is environment-level rather than per-entity, because a connector throttle or auth failure hits every entity the flow serves.
Time window24H (rolling 24-hour run window)
Alert trigger>5. More than five failed integration-flow runs in 24 hours raises an alert. A small handful can be transient; a count above five points at a systemic problem, an expired connection, an API limit, or a downed trigger source.
Rolesowner, finance, engineering

​
Calculation

Calculated automatically from your Microsoft Dynamics 365 data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading.

​
Worked example

A brand runs four Power Automate cloud flows bridging a Shopify Plus storefront to Finance & Operations. The card is read 22 Mar 26 covering the prior 24 hours.
FlowPurposeRuns (24h)Failed
ORDER-TO-SOCreate F&O sales order from storefront order1,18011
SO-TO-INVOICERaise free-text / sales invoice9400
INVENTORY-PUSHPush F&O on-hand to storefront2882
MASTER-SYNCSync customer / item master960
Power Automate Flow Failures (this card)2,50413
Four things to notice:
  1. 13 failures is above the threshold of 5, so the card is alerting. It is not a catastrophic outage (99.5% of runs succeeded), but 13 dropped messages in a day is enough to matter and enough to justify investigation now rather than at month end.
  2. Eleven of the failures are on ORDER-TO-SO. That concentration is the clue. When one flow carries almost all the failures, look at that flow’s connection and the F&O action it calls. A common cause is the F&O OData / connector hitting an API throttle during a traffic spike, returning a 429, and the flow exhausting retries.
  3. Eleven failed order-to-SO runs means eleven storefront orders with no F&O sales order yet. That is the downstream consequence, and it shows up on Commerce Orders without Business Central Sales Order. The two cards move together: flow failures here become missing sales orders there.
  4. The two INVENTORY-PUSH failures will widen inventory drift. Each failed push leaves the storefront showing a stale quantity. If these accumulate, the ERP-vs-Ecom Inventory Variance % gauge climbs. A flow-failure spike here is often the first warning before the variance gauge moves.

​
Sibling cards merchants should reference together

This card is the integration-health early warning. Pair it with the downstream cards that show what the failures broke.
CardWhy pair it with Power Automate Flow Failures
Batch Job Error Queue (24h)The F&O-side sibling. Where Power Automate is the cloud-flow layer, batch jobs are the in-ERP processing layer. Integration problems often show on both.
Ecom Orders Missing Matching D365 Free-Text InvoiceThe financial consequence of a failed invoice-creation flow: orders with no matching invoice in F&O.
ERP-vs-Ecom Inventory Variance %The inventory consequence. Failed inventory-push flows leave the storefront stale, which drives the variance gauge up.
SKUs with D365 vs Ecom Inventory Drift >5%The per-SKU view of that inventory consequence. Use it to see exactly which items a failed push left out of date.
Commerce Orders without Business Central Sales OrderThe order consequence. A failed order-sync flow leaves storefront orders with no sales order in the ERP.

​
Reconciling against Microsoft Dynamics 365

Where to look in Business Central / Finance & Operations: The integration runs in Power Platform, and its effects land in D365. Check both sides:
Power Automate portal > My flows / Solutions > [flow] > Run history (the authoritative list of failed runs with error detail) Power Platform admin centre > Environments > [env] > Analytics > Flow runs (aggregate run / failure counts) F&O > Data management > Data project execution history (whether the data the flow carried actually landed) F&O > System administration > Inquiries > Batch jobs (downstream batch processing the flow triggered)
To verify the count, open the flow Run history filtered to the last 24 hours and to Failed status across the in-scope integration flows; the total should match this card. Each failed run shows the failing action and the error (HTTP 429 throttle, 401 / expired connection, F&O business-logic rejection, or a timeout). That error message is the fastest route to the cause. Common mistakes when comparing by hand:
  • Counting all flows, not just the integration set. The portal shows every flow in the environment. This card counts only the ecom-to-D365 integration flows, so an unfiltered portal count will read higher.
  • Counting retried-then-succeeded runs. A run that failed an action but succeeded after a built-in retry shows intermediate errors in the trace but ends Succeeded. The card counts terminal failures only.
  • Confusing skipped or cancelled with failed. Runs that were skipped (trigger condition not met) or cancelled are not failures.
Why our number may legitimately differ from the portal:
ReasonDirectionWhy
Flow set scopeCard lowerThe card counts only the tagged ecom-integration flows. The portal’s all-flows view includes unrelated automations, so it reads higher.
Terminal vs intermediate failureCard lowerThe card counts only runs that ended Failed. Runs that recovered on retry show errors in the trace but are not counted.
24-hour window edgeEitherThe card uses a rolling 24-hour window; a manual portal filter set to “today” or a fixed clock day captures a different slice near the boundary.
Run-history retentionEitherPower Automate prunes old run history per the environment’s retention policy. A very old failure may be gone from the portal but already counted (or already aged out) by the card.
Throttled-but-queued runsCard lower until resolvedA run delayed by throttling but still retrying is in progress, not failed, so neither side counts it yet.
Cross-connector note: This card sits exactly on the seam between your commerce connector and Microsoft Dynamics 365. A failure here almost always shows up as a downstream symptom on the commerce side (missing order, stale inventory) before anyone notices the flow itself. That is why it is a hero card: catching the flow failure early prevents the order and inventory cards from drifting.

​
Known limitations / merchant FAQs

What is the single most common cause of a spike? An expired or revoked connection. Power Automate connections to F&O and to the storefront use credentials that can expire, be rotated, or lose consent. When that happens every run of the affected flow fails until the connection is re-authorised. The error in the run history will say 401 / unauthorised. The count is high but orders still seem to be flowing. How? Built-in retries and a partial failure pattern. If only some actions in a flow fail, or runs recover on retry, throughput continues while the failure count climbs. Treat a rising count as a leading indicator even when the storefront looks fine, because the downstream order and inventory cards lag it. Does this count internal F&O automations or only the ecom bridge? Only the ecom-to-D365 integration flows: order sync, invoice creation, master sync, and inventory push. Internal F&O-only flows and unrelated business automations are excluded so the card stays a clean signal for the storefront bridge. What does an HTTP 429 in the run history mean? The F&O connector or OData endpoint throttled the flow because it exceeded an API call limit, usually during a traffic spike or a bulk sync. Throttling is the classic cause of a burst of failures on the busiest flow (typically order sync). Spreading the load or adding backoff in the flow resolves it. A failed run, can I just re-run it? Often yes. Power Automate lets you resubmit a failed run from the run history. For an order-sync failure caused by a transient throttle, a resubmit usually succeeds. For a failure caused by an F&O business-logic rejection (a blocked customer, a closed period), fix the underlying record first, then resubmit. Why is the window 24 hours and not since-last-success? Twenty-four hours is the operational review horizon: it catches an overnight batch failure before the morning stand-up. A since-last-success view would hide a flow that has been failing for days but ran successfully once. The fixed window keeps the alert honest. Does this work if we use dual-write instead of cloud flows? This specific card is about Power Automate cloud-flow runs. If your integration is pure dual-write with no cloud flows, the relevant failure signal is on the F&O batch and data-management side; see Batch Job Error Queue (24h). Most commerce-to-F&O setups use cloud flows for the order and invoice path, so this card applies. Will a planned maintenance window inflate the count? It can. If the storefront or F&O is taken down for maintenance, in-flight flows fail. Expect a benign spike during a known maintenance window; the count should return to baseline once the systems are back.

​
Tracked live in Vortex IQ Nerve Centre

Power Automate Flow Failures (ecom integration) is one of hundreds of KPI pulses Vortex IQ tracks across Microsoft Dynamics 365 and 70+ other ecommerce connectors. Nerve Centre runs the detection layer; Vortex Mind investigates the cause when something moves; Ask Viq lets you interrogate any number in plain English. Start for free or book a demo to see this metric running on your own data.