What writes to this column?
Dynamics cannot answer that about itself. Pathix resolves it across forty component surfaces, covering both what writes the column and what reads it. Every edge carries the evidence behind it, and the writes Pathix could not trace get labeled instead of dropped.
One column, every component that touches it.
Writers and readers appear in one ranked list. Each row shows the component kind, the direction of the edge, and how Pathix established it. You can filter by direction or by confidence, export the table to CSV, and click any row through to that component's own page.
Point your agent at this instead of the console. find_writers and find_readers return the same resolved list with the same confidence on every row, read-only, over the Pathix MCP →
The form a visitor fills in, and the number an executive reads.
The path runs from a page on your Power Pages site, through the advanced form it embeds, a plugin, a classic workflow, a cloud flow and a formula column: 6 components joined by 10 resolved edges. No screen in Dynamics shows more than one of those links at a time. Pathix resolves the path from the parsed definition of each component.
Read it as structure, not as traffic. Pathix parsed what each component is defined to do. It did not watch a record move.
- 01POWER PAGES PAGEBook an Appointment form/book-an-appointmentSomeone outside your organization opens the page.
- 02ADVANCED FORMembed tag on the page DETERMINISTIC · DECLAREDC2 Book an appointmentsix steps, each binding a model-driven formThey answer six screens and submit.
- 03TABLEstep metadata binds the columns DETERMINISTIC · DECLAREDmsdyn_appointmentrequestsim_estimatedvalue, sim_referralsourceTheir answers become a record, including an amount.
- 04PLUGINread by the plugin's PostOperation Create step DETERMINISTIC · DECLAREDAppointmentRequestPostCreatenew Entity("sim_bankengagement")Code fires on save and creates a second record from it.
- 05TABLEwritten from IL DETERMINISTIC · PARSEDsim_bankengagementsim_estimatedvalue, sim_producttype, sim_routingtierThe amount is now on a record nobody filled in.
- 06CLASSIC WORKFLOWCheckProperty, a filter read DETERMINISTIC · PARSEDsim_ComplianceReviewTriggerCreateEntity, then SetEntityProperty from the read valueA workflow reads that amount and opens a compliance review.
- 07TABLEcolumn to column, derived DETERMINISTIC · PARSEDsim_compliancereviewsim_exposureamountThe same number, under a different name, on a different table.
- 08CLOUD FLOWtrigger filters on sim_riskscore, sim_status DETERMINISTIC · PARSEDsim_BranchRollupUpdateRecord, read from the flow's clientdata JSONA flow rolls it into the branch's daily totals.
- 09TABLEitem/sim_committedvalue DETERMINISTIC · PARSEDsim_branchdaysummarysim_committedvalue, sim_pendingreviewcountIt is now part of a committed-value total.
- 10FORMULA COLUMNread by the formula expression DETERMINISTIC · DECLAREDsim_capacityutilizationcomputed from sim_committedvalueA formula turns that total into a utilization percentage.
- 11SAVED QUERY + CHARTcharted on the same column DETERMINISTIC · DECLAREDCharted on sim_capacityutilizationAn executive reads the percentage, and sees none of the above.
The first two nodes are where the other half of this lives. Resolving the page, the form it embeds and the columns those steps bind is one problem; deciding who is allowed to load that page in the first place is a different one, with its own surface: what a visitor who never signs in can reach →
The entry point is Microsoft's out-of-the-box scheduling template. Everything downstream carrying a sim_ prefix is a scenario built to exercise the parsers, not a customer environment.
Four calls in one plugin, resolved four separate times.
This is why a single score per component would be useless. Pathix resolves each call on its own terms rather than grading the assembly as a whole: one is pinned by a registration, the rest are read out of the IL, and two are not edges at all but findings in their own right.
The chain closes back on where it started.
A plugin four hops down writes msdyn_appointmentrequest.sim_syncstatus back onto the table the chain began from. Drawn as a tree that edge simply disappears, and with it the reason a change made late in the chain can surface at the beginning of it.
Reads are dependencies too.
Writers tell you what can change a column. Readers tell you what breaks when it does, and those are different problems. Pathix models both directions and labels the kind of dependency, because a chart that displays a value fails very differently from a flow trigger that branches on it.
Write edges carry two further details. One is conditionality: does the write always fire, or only inside a branch. The other is origin, which separates a person editing a form from an automation running on its own.
Every edge says where it came from.
If you cannot check how a dependency was found, you are taking the list on faith. Every edge carries one of 3 confidence tiers. Pathix never averages them into a single score, and it shows the weakest tier as plainly as the strongest.
Either the platform's own structure pinned the target, or Pathix read the component's logic and resolved the exact column from it. Both are certainties rather than estimates, which is why they now read as one tier: the distinction between them is how Pathix knows, not how much it knows, and that belongs on the row rather than in the headline.
An optional AI pass read decompiled code and proposed an edge the parser had missed. It arrives with the evidence that justifies it attached, it is net-new only, and it can never override a deterministic edge. Dismissing one hides it without destroying it.
Pathix found a write and could not trace what it targets, usually because the column name is assembled at runtime. It keeps a tier of its own so the write stays visible instead of being silently dropped, which is the whole reason it is not simply omitted.
Open a deterministic row and it says which of the two ways it was resolved. That is a method, not a grade: both are certainties, and neither outranks the other.
the platform's own structure pinned the target: a step registration, a manifest, a binding, a column mapping.
Pathix read the component's own logic and resolved the exact column out of it: compiled plugin IL, workflow XAML, a flow's definition JSON, a JavaScript syntax tree, a Power Fx expression.
A plugin ships as compiled IL, so the platform's own dependency tracking stops at the registration and never sees the column assignment inside. Pathix decompiles the assembly and walks the IL for column-level reads and writes. That covers assemblies shipped by a vendor, which you opt into and can exclude per publisher. Vendor code writes to your columns like anything else, and skipping it would leave a gap in the graph exactly where you have no other way to look.
A role that grants write access is not a writer.
Granting the ability to write is not the same as writing. Pathix keeps them on separate surfaces on purpose: write edges live in the dependency graph, and who can write lives with the roles and principals. They never merge into one edge.
Blur the two and a permission starts looking like a dependency, which is the confusion an access review exists to prevent. The dependency graph answers what could change this value. The roles and principals answer who could, and a list that mixes them is not a reliable answer to either one.
What structural parsing misses, and what closes it.
Any tool that claims to find everything is guessing somewhere. Two gaps are worth naming. Pathix labels both in the product, so a clean-looking list never implies more certainty than it has.
A late-bound or dynamically assembled column name cannot be resolved from structure alone. Pathix marks the write Unresolved and adds it to a worklist rather than guessing at a target. With AI enabled it reads the decompiled or original source and can propose an evidence-coupled edge for some of them, so the gap is smaller than the parser alone would leave it.
Pathix traces bound properties from the manifest through each form binding. A control that takes its column name from runtime configuration is a documented gap in the coverage register.
Canvas apps are the one place depth is a setting rather than a limit. Standard parsing resolves them as far as the table; switch deep scan on for an environment and Pathix unpacks the app package for column-level attribution.
All of which is why an empty result is worded carefully. A column with no writers means no scanned surface resolved a write to it. Treat that as a strong lead worth checking, well short of a guarantee that nothing can write it.
You can do this by hand.
Both guides work whether or not you ever buy anything, including the parts where the manual approach gives out.
The full manual method against a solution export, including the two surfaces you cannot inspect without tooling.
Read the guide →What the platform's dependency tracking actually covers, what it cannot see, and why that is a design choice rather than a bug.
Read the guide →Try it on a column you already worry about.
A walkthrough runs the real console on a sample environment. Open a column, filter by confidence, and see what the answer looks like before anyone touches your tenant.