Your flow failed on step nine, and the error is about a property that doesn't exist. Somewhere between the trigger and the failure, a value quietly became something other than what you assumed. Compose tells you what it actually was, in about thirty seconds.
How to do it
- Open the flow in edit mode and find the action that keeps misbehaving.
- Add a new step directly above it. Search for Compose (it sits under Data Operations) and add it.
- In the Inputs box, put the thing you're unsure about: the dynamic content token, the expression, the whole array. Anything that resolves to a value.
- Save, then run the flow once.
- Open the run history, click into the Compose step, and read Outputs. That is the exact value your next action was about to receive.
Rename it to something like DEBUG customer email while you're there. Future you needs to know which steps were scaffolding and which ones do the work.
Why it works
Every action already shows its raw outputs in the run history, but they arrive as one large JSON blob and the thing you care about is usually five levels down inside it. Compose narrows the question. You stop asking "what did SharePoint return" and start asking "what does this one expression evaluate to, right here" - and the answer comes back as a single readable value instead of a JSON dig site.
It also doesn't touch anything. Compose takes an input and hands it straight back. No connector call, no data changed, no email sent. Dropping one into a live flow can't break the flow, which is what makes it safe to add before you understand the problem rather than after.
When not to use it
Two limits worth knowing. Whatever you put in a Compose is stored in plaintext in the run history, so it's the wrong tool for inspecting a token, a password, or anything else you'd rather not leave sitting in a log for 28 days. And built-in actions still count toward your API request limits, so a Compose parked inside an Apply to each processing 400 rows is 400 extra requests. Debug with it, then delete it.
If the value turns out to be exactly right and the action fails anyway, the problem isn't your data. That's a retry policy conversation instead.