> ## Documentation Index > Fetch the complete documentation index at: https://docs.vortexiq.ai/llms.txt > Use this file to discover all available pages before exploring further. # Power Automate Flow Failures (ecom integration), Microsoft Dynamics 365 > Power Automate Flow Failures (ecom integration) counts failed cloud-flow runs linking your store to D365 in 24h. How to read it, why it matters, and how to act. **Card class:** [Hero](/nerve-centre/overview#card-classes-explained) • **Category:** [Ecommerce Platform](/nerve-centre/connectors#connectors-by-type) > 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 counts** | Failed 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 scope** | Only 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 flows** | The 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 entity** | Where 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 window** | `24H` (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. | | **Roles** | owner, 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. | Flow | Purpose | Runs (24h) | Failed | | -------------------------------------------- | --------------------------------------------- | ---------- | ------ | | ORDER-TO-SO | Create F\&O sales order from storefront order | 1,180 | 11 | | SO-TO-INVOICE | Raise free-text / sales invoice | 940 | 0 | | INVENTORY-PUSH | Push F\&O on-hand to storefront | 288 | 2 | | MASTER-SYNC | Sync customer / item master | 96 | 0 | | **Power Automate Flow Failures (this card)** | | **2,504** | **13** | 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](/nerve-centre/kpi-cards/microsoft-dynamics/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 %](/nerve-centre/kpi-cards/microsoft-dynamics/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. | Card | Why pair it with Power Automate Flow Failures | | ------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- | | [Batch Job Error Queue (24h)](/nerve-centre/kpi-cards/microsoft-dynamics/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 Invoice](/nerve-centre/kpi-cards/microsoft-dynamics/commerce-orders-without-business-central-sales-order) | The financial consequence of a failed invoice-creation flow: orders with no matching invoice in F\&O. | | [ERP-vs-Ecom Inventory Variance %](/nerve-centre/kpi-cards/microsoft-dynamics/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%](/nerve-centre/kpi-cards/microsoft-dynamics/inventory-sync-drift) | 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 Order](/nerve-centre/kpi-cards/microsoft-dynamics/commerce-orders-without-business-central-sales-order) | The 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:** | Reason | Direction | Why | | ------------------------------------ | ------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Flow set scope** | Card lower | The card counts only the tagged ecom-integration flows. The portal's all-flows view includes unrelated automations, so it reads higher. | | **Terminal vs intermediate failure** | Card lower | The card counts only runs that ended Failed. Runs that recovered on retry show errors in the trace but are not counted. | | **24-hour window edge** | Either | The 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 retention** | Either | Power 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 runs** | Card lower until resolved | A 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)](/nerve-centre/kpi-cards/microsoft-dynamics/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](https://app.vortexiq.ai/login) or [book a demo](https://www.vortexiq.ai/contact-us) to see this metric running on your own data.