Which flow changed this Dynamics 365 record?

Examples come from the Flow Trace demo estate, RautingTech's own test environment. No client data or client work is described.

The ticket lands at 4:40 on a Friday. A dispatcher says a work order changed status on its own — went from Scheduled to Completed before anyone touched it, and now a technician is standing at an empty address. The customer is on the phone. The only fact anyone can hand you is a GUID: the record id of the work order.

That GUID is the whole case file, and on its own it is almost useless. It doesn't say which of the dozen or so flows running in this environment might have written to that record. It doesn't say whether a person made the change, a plugin did, or a scheduled job did. Somebody has to work backward from "the record changed" to "here is what changed it," and Dataverse was never built to answer that question directly.

The old way

Here is what backward used to look like. You open the maker portal and start with the flow you suspect — the one that sounds closest to "work order completed," because you have to start somewhere. You open its run history. You scan the list for something that ran around the right time, which means eyeballing timestamps against a customer's vague sense of "sometime this afternoon." You open a run, and its trigger payload is a wall of JSON. You search that payload for a record id, because the run list itself doesn't show which record a run touched — you have to open each one to find out.

If that flow's payload doesn't match, you close it and try the next flow on your list of suspects. And the next. Every detour costs a few minutes and tells you nothing about whether you're getting warmer — you either find the record id in this run's payload or you don't, and you move on. Meanwhile the plugin trace log, the async job queue, and the audit history are three more places the same record might have been touched, each with its own screen, its own filters, its own login.

This isn't a skill problem. It's a structural one: Dataverse's flowrun table — the table that lists every run of every flow — has no column for the record the run touched. That link exists only inside each run's trigger payload, one run at a time. Nobody built the join, because the platform doesn't carry the data to build it with.

The moment

Flow Trace's record trace exists because someone got tired of doing that join by hand, for every ticket, forever. You paste the GUID — no need to know or declare which table it belongs to, Flow Trace's record trace works that out — pick a window (the last 24 hours, the last week, or "around this moment" if the customer only gave you a rough time), and it hands back one ordered timeline: every cloud flow run correlated to that record by its trigger payload, every async job against it, every audit row if auditing is turned on, and plugin activity for context.

Instead of four screens, there is one list, in time order. Instead of "a flow ran," you get "the flow that runs when a work order is marked Completed ran at 4:17, and it failed." Click show actions on that run and you get the action-by-action execution: which steps succeeded, which one failed, how long each took, and — this is the part that saves the phone call — the actual error text. In this kind of case, it usually reads something as specific as "Create invoice" failing because "Price list missing for product 'ERP-1042.'" That is not "the flow broke." That is the sentence you put in the ticket.

The action list also shows what got skipped after the failure. A flow that stops mid-run doesn't just fail one step — everything downstream of that step never executes, and now you know why the work order shows a Completed status with no invoice behind it and nobody notified. One failed action explains the whole symptom the customer called about.

What changes afterward

The first change is speed, and it's the obvious one: a ticket that used to mean five browser tabs and cross-referencing timestamps by eye now means pasting one string into one box. The plain version of that pitch is almost too flat to need writing down — support goes from "the workorder changed by itself" to the exact flow, run, and failing action in under a minute.

The less obvious change is what it does to the shape of the support conversation. A trace produces a shareable deep link — the record id and the time window baked into a URL — so instead of describing what you found, you hand the next person the exact view you're looking at. A CSV export turns the same timeline into something that can sit in a ticket or a postmortem without anyone retyping timestamps by hand. And because Flow Trace's record trace remembers what's been traced recently, the records support keeps coming back to — the account that generates three tickets a week, the process everyone half-suspects — show up as one-click suggestions instead of GUIDs pasted into a notes file somewhere.

There's a quieter shift too, in what support stops doing. Nobody opens the maker portal to page through a flow's run history hoping to recognize a timestamp. Nobody treats a trigger payload's JSON as a search target. The question "which flow was it" stops being a guess you make before you can start investigating, and becomes a fact the tool hands you as the starting point. That's the actual triage epiphany: not that tracing got faster, but that guessing stopped being part of the job.

Plugin activity shows up too, but it's marked as uncorrelated and hidden by default — Dataverse doesn't record-correlate plugin traces the way flow triggers can be correlated, so Flow Trace's record trace is honest about the difference between "we matched this to your record" and "this happened in the same window and might be related." That distinction matters the first time a trace almost sends you chasing the wrong plugin.

None of this changes what caused the outage in the first place. A flow that fails because a price list is missing still needs someone to fix the price list. What changes is how long it takes to know that's the cause, and how much of the investigation is guesswork versus fact. The engineer who used to open five tabs and hope now opens one, pastes one GUID, and reads the answer off the screen.

A live one, from our own tenant

This is not hypothetical. Our own dev environment carries a flow called On account update that Flow Trace's rules and Fix list had flagged under No self-trigger loops — it updates the same table it triggers on, with no guard. It had been switched off since August. On the evening of 8 September we switched it on for three minutes to generate some fresh run history for a demo and touched three account records.

Flow Trace's record trace on one of those accounts showed the flow firing, failing on Update a row, and firing again — roughly fifty-five failed runs against that single record in under two minutes, the same on the other two. Across the three records the next ingest picked up 164 new failed runs. The flow was switched off again inside four minutes, and the run count stopped dead at the same second.

Nothing about that was clever. The point is what it took to see it: one GUID, one paste, one timeline. The lint rule had said this flow is a loop weeks earlier; the trace showed the loop happening, in time order, with the failing action named. That is the whole product in one screen.

See it yourself

None of this requires believing a sales page. Flow Trace installs into your own Azure subscription (the Azure Marketplace listing is on its way; early access installs are set up with you), connects to your environments with a read-only role, and reads your run history on its first pass. Then you paste a record ID you already know is a problem. The first trace you run is the real one, against your own data. If it doesn't save you the four-tab hunt on the first ticket you try, you'll know straight away.

Request early access or score your estate first.