The Call You Don't Want to Get
A client contacts you because deposits are missing from their spreadsheet. Not one — several. And the flow that writes them has been failing for ten days.
This happened to me in March 2026 with a client in the hospitality business. A Power Automate flow captures paid deposits from Tripleseat webhooks and writes them to an Excel table on SharePoint. The flow had been running fine for months. Then it stopped — silently — and nobody noticed until the discrepancy showed up in a reconciliation.
The root cause turned out to be a single stale GUID. But before I could fix anything, I needed to know exactly what the flow had missed.
What the Flow Does
The flow listens for UPDATE_EVENT webhooks from Tripleseat. Every time a booking is updated, the webhook fires. The flow checks whether there's a paid deposit, and if there is, it writes one row to an Excel table: location, deposit date, amount, event name, event date, contract link, grand total.
Simple. Write-only. No memory, no deduplication built in.
Why It Failed
The Excel file had been moved in SharePoint. When that happens, the internal GUID that Power Automate uses to reference the table goes stale. Every attempt to write a row fails with an itemNotFound error.
The flow doesn't send alerts when this happens. It logs the failures in the run history, but if nobody is monitoring that, the failures accumulate silently. By the time I looked, there were 59 failed runs over a 10-day window.
The fix itself takes five minutes:
1. Open the flow in Power Automate designer
2. Click the "Add a row into a table" action
3. Re-browse to the Excel file
4. Save the flow
That updates the GUID and the flow starts working again. I did this first before anything else.
The Harder Question: What Did We Lose?
Fixing the GUID stops the bleeding. But it doesn't tell you what's already missing from the spreadsheet.
59 failed runs sounds like 59 missing rows. It isn't. Most webhook fires are updates to events that don't have paid deposits yet — someone edited a note, changed the event date, updated a contact. Those would have been filtered out by the flow's own logic even if the Excel action had worked.
I needed to replay the same logic the flow would have applied and find out which runs, if any, had genuinely paid deposits that never made it to the spreadsheet.
The Approach: Hit the Run History API
Power Automate has an API that gives you access to a run's full trigger body — the original webhook payload that fired the flow. This is only available for recent runs (older runs age out). For the March 2026 window, everything was still accessible.
The script I wrote does two things:
Step 1 — Inspect: For each of the 59 run IDs, fetch the original Tripleseat webhook payload from the API. Apply the flow's filter logic: check payment.state. If it's "paid", extract the row fields. Write them to rows_to_add.csv.
Step 2 — Deduplicate: The flow has no deduplication. Tripleseat fires multiple webhooks on rapid saves, so the same paid deposit can appear in several failed runs. Dedup rule: same Event Name + same Deposit Amount = duplicate, keep one.
The script ran in about 15 minutes on a batch of 59 runs with a 10-worker thread pool.
What We Found
Of the 59 failed runs:
- 51 had
payment.state == "new"— the flow would have skipped them anyway. Not data loss. - 8 had confirmed paid deposits that never reached the spreadsheet.
- After deduplication: 5 unique rows were genuinely missing.
That's the number that mattered. Five rows, all from the March 21–31 window, all with matching entries in Tripleseat that just never made it into Excel.
We pasted them in manually. Reconciliation closed.
The Auth Piece
The API requires a bearer token from your Power Automate session. Tokens expire in about 76 minutes, so you need a fresh one immediately before running the script.
The fastest way to get one: open make.powerautomate.com, open DevTools, filter Network requests for api.powerplatform.com, navigate to the flow's run history, and copy the Authorization: Bearer eyJ... header from any request.
If you need it to last longer, Azure CLI works: az login followed by az account get-access-token. That auto-refreshes.
What to Monitor to Catch This Earlier
The Excel table GUID issue is specific to SharePoint — if the file gets moved or recreated, every Excel action in every flow that references it breaks. This is not obvious from the Power Automate UI unless you're actively watching the run history.
Two things would have caught this faster:
1. A failure alert. You can add a parallel branch to any flow that runs when the main branch fails, sends an email or Teams message. One action. I set this up for the client after the investigation.
2. Regular run history checks. Power Automate shows a summary of recent runs. If you're managing a flow for someone, build a 5-minute weekly spot-check into whatever maintenance routine you have.
The GUID error will happen again if someone moves the file. Now there's an alert.
The Actual Script
The script is about 150 lines of Python, uses requests and tqdm, runs with --limit N for testing.
One honest note: getting the API endpoint right took longer than I expected. The older api.flow.microsoft.com endpoint returns 401 with the same token. The correct one is the environment-scoped endpoint at https://default{env_id}.ef.environment.api.powerplatform.com. You can find it in the DevTools Network tab on the run history page — it's the same URL the browser is already calling.
If you're investigating your own flow outage, start there.