What writes to this field?
Dynamics cannot answer that about itself. Pathix resolves it across twenty-five component types, 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 labelled 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.
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 four confidence tiers. Pathix never averages them into a single score, and it shows the weakest tier as plainly as the strongest.
Platform structure pins the target, through a registration, a manifest, or a binding. Pathix inferred nothing here.
Pathix resolved the exact column from the component's own logic, whether that was compiled IL, workflow XAML, flow definition JSON, or a JavaScript syntax tree.
A model read decompiled code and proposed an edge the parser had missed. It arrives with its evidence attached, it cannot override a deterministic edge, and dismissing it hides the edge without destroying it.
Pathix found a write but could not trace its target, usually because the column name is assembled at runtime. It gets a tier of its own so the write stays visible.
A plugin ships as compiled IL, so the platform's own dependency tracking stops at the registration and never sees the field 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.
The demo is the real console running on a sample environment. Open a field, filter by confidence, and see what the answer looks like before you talk to anyone.