Fixing "Null" and "Array is Empty" Exceptions in Power Automate Triggers
Published on April 26, 2026
Few failures are as disorienting as a Power Automate flow that works perfectly in testing, then crashes in production the moment real data starts flowing through it. Among the most common culprits is a deceptively simple problem: your flow fires before the data it needs has fully arrived.
The result is a cascade of "Null" or "Array is empty" exceptions — typically surfacing when processing trigger output expressions like @triggerBody()?['value'] on newly created items. Understanding why this happens, and how to defend against it, is essential for any team running production automation on Microsoft 365.
Null and empty array errors are timing problems as much as logic problems — defensive patterns are the cure.
Why Trigger Data Arrays Arrive Null or Empty
When a trigger fires — for example, "When an item is created" in SharePoint or a Dataverse row trigger — Power Automate executes nearly instantly. However, the platform's internal event bus and the underlying data service are not always perfectly synchronized. In the milliseconds between item creation and trigger execution, dependent lookups, related record hydration, or expanded column values may not yet be available.
When a flow tries to read @triggerBody()?['value'] and the value collection hasn't fully populated, the expression resolves to null — or if iterated, to an empty array. Any downstream action that depends on that data will fail, often with a misleading error that obscures the real timing root cause.
Common scenarios where this manifests include:
- Reading a lookup column on a newly created SharePoint list item before indexing completes
- Iterating over a related Dataverse collection that hasn't finished relationship hydration
- Accessing OData expanded properties on a new record via HTTP connector immediately after creation
- Processing webhook payloads from third-party systems that deliver partial data on the initial event
Pattern 1: Null-Safe Expressions with the Coalesce Function
The first line of defense is to make your expressions null-tolerant. Rather than referencing trigger output directly and letting the flow crash on null, wrap the reference in a coalesce expression that substitutes a safe default when the value is absent.
For example, instead of:
Use:
For arrays specifically, combine coalesce with an if expression that checks length before iterating:
This ensures that even if the trigger payload is incomplete, your flow continues executing safely rather than crashing and generating noise in your run history.
Null-safe expressions using coalesce and conditional logic prevent crashes when trigger data is incomplete.
Pattern 2: Delay and Re-Fetch Instead of Relying on Trigger Payload
For scenarios where the trigger payload is structurally incomplete — not just null — the most reliable fix is to not use the trigger payload as the data source at all. Instead, use the trigger only as a signal that an event occurred, then re-fetch the data explicitly after a brief delay.
The approach:
- Add a Delay action (even 5–15 seconds) immediately after the trigger to allow the data layer to settle
- Use the item ID from the trigger — which is always reliably present — to perform a Get item or Get row action
- Build all downstream logic on the re-fetched data object, not the original trigger body
This pattern is especially effective for Dataverse triggers, where relationship expansion and calculated columns can lag by several seconds after record creation.
Pattern 3: Condition Gates Before Array Iteration
Before any Apply to each loop that operates on trigger-sourced arrays, add a Condition action that validates the array is both non-null and non-empty. Only branch into the loop if the condition passes. Place error-handling or logging logic in the "No" branch so failures are captured rather than silently skipped.
This single gate eliminates the majority of "Array is empty" runtime failures in trigger-based flows and makes your run history far easier to interpret.
Condition gates before array iteration stop failures before they start and improve run history clarity.
Pattern 4: Configure Run After for Graceful Error Capture
Even with null-safe expressions and condition gates, exceptions can still escape. Use Configure Run After on a dedicated logging or notification action set to run on Has Failed, Has Timed Out, and Has Been Skipped. This ensures that when a trigger-timing failure does occur, your team is alerted with context — not left hunting through failed run logs manually.
Combine this with a Compose action that captures the raw trigger body at the top of the flow. This snapshot is invaluable for diagnosing exactly what data was present — or absent — when the failure occurred.
Build Flows That Survive the Real World
Trigger-timing failures are not edge cases — they are the inevitable result of building event-driven automation on top of distributed systems. The flows that remain reliable in production are the ones built with explicit defensive patterns, not optimistic assumptions about data availability.
Key takeaways for your team:
- Never assume trigger payload arrays are fully populated — always validate before iterating
- Use coalesce as your standard expression pattern for any trigger-sourced value
- Prefer re-fetching data by ID over consuming raw trigger payloads for critical workflows
- Gate all array loops with explicit null and length checks
- Configure Run After on error-handling steps so failures are observable, not silent
Are your flows crashing with null exceptions or empty array failures in production?
Jsquared Solutions offers the Power Automate Diagnostic Clinic — a focused engagement designed to identify brittle trigger patterns, strengthen error handling, and restore run reliability. Explore our service packages or Book a Consultation to get your automation ecosystem back on solid footing.
