PathixDataverse Forensics
Planning · architect, consultant & IT lead

Change a table without
breaking production.

The impact analysis that used to take a week of reading decompiled code is now a scan and a few questions. You still make the calls, but you make them knowing what is connected to what, instead of finding out in production.

Book a demoSee the whole picture

Prefer the capability list? Every change-impact feature, itemized →

Table logic footprint

Everything bound to a table, in one call.

Point Pathix at a table and it returns every component that touches any column on it, with the columns each one writes or reads folded in. You see which components exist only because of how the table is shaped today, and which carry rules you have to preserve. That is the migration, visible up front instead of three weeks in.

Pathix logic footprint for the account table: 12 components, one row each, with the columns each one writes and reads folded in, plus type, enabled state, a confidence tier (Parsed here), parse status, and the source parser. A note flags that canvas-app deep scan is disabled for this environment, so canvas-app column reads and writes may be undercounted.
Rewrite plan

A leaf-first rewrite order that flags its own unproven edges.

Point Pathix at a table and it returns a leaf-first rewrite order, with column data flow and orchestration coupling in one sequence. Cycles with no provable internal order, edges it could not resolve, and components it could not place are marked, not dropped. Verify the order before you build to it.

1 cycle group · 2 unproven edges · 2 tracks  Hover a component to trace what it reaches.
thenpoints from what you change first to what depends on it. It is not a “depends on” arrow.
cycleno provable internal order, so the group migrates together.
unprovenPathix could not resolve the link. It stays in the plan, and you verify it.
Trackan independent cluster. Different tracks share nothing and can move in parallel.
WAVE 0 safe to change firstWAVE 1WAVE 2TRACK 0TRACK 1↺ no provable internal orderDFDataflowCredit DataflowPLGPlugin stepFetchXmlCreditLimitMAPAttribute mappingaccount → contactJSForm scriptaccountcreditlimit.jsHTMLHTML web resourcecredit_limit_managerWFClassic workflowOn Create - Set DefaultsFLWCloud flowOn Create UpdateAPICustom APIpathix_SetCreditLimitWFClassic workflowDISABLEDWorkflow with ChildWFClassic workflowDISABLEDChild Workflow
A reduced model of the real view, with the same interaction.
See the real one
Pathix rewrite plan for the account table, drawn as a grid. Waves run left to right as an order: wave 0 is labeled safe to change first, then wave 1, then wave 2. Tracks stack vertically and are independent. Track 0 spans all three waves, running dataflows, a plugin step and attribute mappings into a cycle group of a form script and an HTML web resource marked no provable internal order, then out to classic workflows, a cloud flow, a dialog, an action, plugin steps and a custom API. Track 1 is two disabled classic workflows, a parent and its child. Track 2 is a single attribute mapping. Above the grid the view reports 1 cycle group, 1 orchestration call, 12 unproven edges and 16 components registered with no column edge, and states that absence reflects scanned coverage only and should be treated as a candidate to verify, not proof the field is unused.

A rewrite plan drawn as a grid. Waves run left to right as an order: wave 0 is safe to change first, then wave 1, then wave 2. Tracks stack vertically and are independent, so no edge ever crosses between them. Track 0 runs a dataflow, a plugin step and an attribute mapping in wave 0, into a cycle group in wave 1 holding a form script and an HTML web resource marked no provable internal order, and out to a classic workflow, a cloud flow and a custom API in wave 2. Two of its edges are dashed because they are unproven. Track 1 is a disabled classic workflow and its disabled child. Track 0 and track 1 could be worked at the same time by different people without either waiting.

What's covered

A write has nowhere to hide.

40 surfaces today · 2 more on the way

Everything above is only as good as what Pathix can read. These are the surfaces it parses; the security model is scanned separately.

AUTOMATION
What writes to columns
  • Plugin steps
  • Plugin assemblies (IL)
  • Custom APIs
  • Classic workflows
  • Dialogs
  • Actions
  • Business rules
  • Business process flows
  • Cloud flows (Power Automate)
  • Dataflows (Gen2)
  • Dataverse functions (low-code plug-ins)
UI AND CLIENT CODE
Where people meet the data
  • Form scripts (JavaScript)
  • HTML web resources
  • Ribbon and command bar
  • PCF controls
  • Canvas apps
  • Forms
READ DERIVATION
What the platform computes
  • Formula, calculated and rollup columns
  • Attribute mappings
  • Saved queries
  • Charts
  • Dashboards
CONFIGURATION AND INTEGRATION
How it is all wired together
  • Connection references
  • Custom connectors
  • Service endpoints and webhooks
  • Solutions
  • Choices
POWER PAGES
What a site serves to visitors
  • Web pages
  • Web templates
  • Content snippets
  • Basic forms
  • Lists
  • Advanced forms
  • Server logic
  • Web files
AI ESTATE
What the AI is built to touch
  • Copilot Studio agents
  • Agent flows
  • AI Builder models and prompts
  • AI prompt columns
  • Knowledge sources
NOT SHIPPED YET
AI prompts as reusable componentsAI Builder model bindings
Cascade analysis

See the blast radius before you touch a cascade.

Change a relationship behavior and the reach can be enormous and invisible. Pathix lays out the full cascade fanout for a table before you touch it: how far it reaches, how deep, whether a delete cascades or clears the reference, and which tables feel it.

Pathix cascade fanout for the account table: 43 direct and 1,732 total cascade edges, with depth, behavior, the tables they cascade to, and relationship names.
The hard case: a real migration

We gave an AI agent the graph, not a migration plan. It rebuilt the plan anyway.

On a synthetic demo environment, we gave an agent a real normalization job with no plan and junior-developer prompting. Working off the Pathix graph, it rebuilt the whole target model: one overloaded table resolved into four, every plugin's disposition mapped, a sequenced migration drafted. A second agent from a different maker, same graph, drew the same answer. The plan comes from the structure underneath, not the model.

And it caught what a schema diagram never would. Five of the six plugins on that table silently swallow their own errors, which means the rollups and totals sitting in production may already be wrong. The plan's instruction is blunt: recompute those values on migrate, do not trust-migrate them.

Read the migration plan it produced →

With AI on: an agent drafts the migration plan straight from the graph, with the disposition of every component and the data-integrity catches a static diagram can't show.

The leave-behind

The artifact you hand your boss, your board, or your auditor.

One click produces a printable Environment Report: a state-of-the-environment writeup with remediation and control mappings, and an explicit note on what was and was not scanned. It is what you put in front of someone who will never open the tool.

Bring the table that scares you.

A 30-minute walkthrough on a pre-scanned demo environment. We'll trace whatever you're afraid to change.

Book a demo
© 2026 Pathix L.L.C. · self-hosted · metadata-only
Not affiliated with Microsoft. Dynamics 365, Dataverse, and Power Platform are trademarks of Microsoft Corporation.π