PathixDataverse Forensics
How it works · Coverage model

What writes to your columns. Where the gaps are.

Pathix scans your D365 environment across forty component surfaces and emits an honest dependency graph. Every edge carries a parser source, a confidence level, and the boundary it observes, so you can tell at a glance which edges came from deterministic analysis and which came from a model.

Confidence levels: Deterministic (the exact target resolved, with nothing inferred), AI-derived (read from decompiled code, always with attached evidence), and Unresolved (a write seen but not resolved to an exact column). AI never overrides what the deterministic engine proves.

Put plainly: Deterministic means we resolved the exact column and guessed at nothing, whether the platform told us or we read the component's own code. Open the row and it says which: parsed from plugin IL, or declared by a registration. AI-derived means a model proposed it and attached its evidence, and Unresolved means we saw the write and could not pin the column, so we say so rather than drop it.

When Pathix sees that a dependency exists but can't resolve the exact column (a dynamic or computed target), it emits the edge and says so, rather than guessing one.

Book a demoSecurity architecture
The model

One scan, four stages, no record data.

A Pathix scan is a deterministic pipeline. Each stage operates on the output of the last; the metadata-only boundary holds throughout.

01
Ingest registrations
Pathix pulls component registrations directly from Dataverse: plugin steps, cloud flows, classic workflows, dataflows, web resources, ribbon XML, security roles, custom controls, canvas apps, saved queries, forms.
02
Parse the bodies
Each component body is parsed in-process: Mono.Cecil for plugin IL, real AST parse for form scripts, structural walks for JSON / XAML / FetchXML / PowerFx / formxml. Customer code is read once, never persisted.
03
Extract dependencies
Static analysis emits column-level writes and reads, plus the structural metadata around them: table, kind, conditional flag, confidence. AI-derived edges are tagged so reviewers can separate them from deterministic ones.
04
Stitch the graph
Edges land in a relational store keyed by (table, column). Cascade fanout, hierarchy rollup, ribbon binding fan-out, and form-script attribution glue the surfaces together so one-hop questions are direct answers.
FIRST SCANunder an hour · most envs
RE-SCANincremental · skip-unchanged
HISTORYevery scan delta retained · diff via SQL

Scan time tracks the size of your metadata, not the size of your data. A table with a hundred records and a table with a million scan the same, because Pathix never reads a record. What moves the number is how much customization has accumulated, and that grows far more slowly than most people expect. The one thing that does add real time is optional AI narration across a large plugin estate, since each assembly is decompiled and summarized once per version.

Architectural boundaries

Three rules we don't break.

The metadata-only guardrails everything downstream rests on. Enforced in code, not just policy.

Pathix does not
Pathix does not store, transmit, or analyze customer record values.
Metadata-only by design. Pathix ingests structural metadata (schema, registrations, definitions) and behavioral configuration (plugin steps, workflow XAML, flow JSON, form scripts). Record values, audit log payloads, embedded literals from execution traces — never.
ROADMAP
Permanent.
Pathix does not
Pathix does not correlate against audit logs to discover observed-runtime writes.
Audit log ingestion is a separate plane with its own data-residency and retention concerns. v1 stays static-analysis-only.
ROADMAP
v2 candidate. Not committed.
Pathix does not
Pathix does not scan customer-owned source repositories (GitHub, Azure DevOps).
Out-of-Dataverse source ingestion is a separate scoping question with its own auth model.
ROADMAP
v2 candidate. Not committed.
The boundary list is enforced in code, not just policy. Read the schema yourself.Your data →
What's covered

Every surface Pathix parses, and what each one gives up.

40 surfaces today · 2 more on the way

The components Pathix analyzes, grouped by how they participate in the dependency graph. The security model is scanned separately: roles, privileges, principals, teams, business units and column security are their own surface, not one of these.

SURFACE
WHAT PATHIX EXTRACTS
AUTOMATION · what writes to columns
Plugin steps
Registration metadata, message, stage, mode, filtering attributes, images, execution order, impersonation, eventhandler routing (plugin type, service endpoint or webhook), and the shape of secure and unsecure configuration.
Plugin assemblies (IL)
Decompiled IL walked for column writes and reads, related-table writes, exception-handling shape, and self-table writes.
Custom APIs
Discovery, registration, and invocation edges.
Classic workflows
XAML parse across workflow categories 0 to 3: writes, reads, and conditions.
Dialogs
The same XAML parser path as classic workflows.
Actions
The same XAML parser path as classic workflows.
Business rules
XAML category 2, including form-scoped rules that flip conditionality on form actions.
Business process flows
Per-stage required-column write attribution.
Cloud flows (Power Automate)
Definition JSON walk: Dataverse connector actions, trigger configuration, trigger column filters, HTTP-trigger auth mode, expression-body reads, and child-flow and connector invocations.
Dataflows (Gen2)
Power Query M parse with lineage tracking.
Dataverse functions (low-code plug-ins)
One component per Power Fx expression, whether reached as an instant function, a Function created in Power Apps or an automated low-code plug-in. Patch, Collect and Remove writes per column; Filter, LookUp, Search, Sort, First and Last reads; the registration that names it; and the platform's own required-column map compared against what the parser resolved, so a gap is counted rather than silent.
UI AND CLIENT CODE · where people meet the data
Form scripts (JavaScript)
Esprima AST plus a dataflow tier: setValue and getValue, Xrm.WebApi calls, FetchXML literals, four handle-shape variants, and conditional detection by brace depth.
HTML web resources
Embedded JavaScript extraction plus a jQuery AJAX recognizer.
Ribbon and command bar
RibbonXml parse with handler-origin classification. Microsoft platform-default commands are filtered at ingestion.
PCF controls
Manifest tier: bound property declarations fanned out per form binding.
Canvas apps
PowerFx walker over Patch, Update, UpdateIf, Collect, Remove and SubmitForm, plus Filter, LookUp and Search reads. Standard tier is table-level; deep scan, opt-in per environment, unpacks the .msapp for column-level attribution.
Forms
formxml walk: column presence, read-only state, required level, visibility, quick-view transitive embeds, and deprecated controls.
READ DERIVATION · what the platform computes
Formula, calculated and rollup columns
PowerFx and XAML walkers for read-side derivations.
Attribute mappings
Parent-to-child copy, modeled as a synthetic platform component.
Saved queries
FetchXML parse for read references.
Charts
FetchXML parse for read references.
Dashboards
Resolved transitively through the views and charts they embed.
CONFIGURATION AND INTEGRATION · how it is all wired together
Connection references
Denormalized binding edge to flows, connector identity, and bound or unbound state.
Custom connectors
The definition behind a connector identity: destination host parsed from the OpenAPI document, the declared authentication scheme (the scheme only, never a key or token), operation count, and authorship from the owning solution. Microsoft's standard connectors have no definition to read and never will.
Service endpoints and webhooks
Contract metadata only: endpoint URL, auth scheme type, whether a key is present, and header names. Header values, SAS keys and connection-string secrets are dropped at the wrapper boundary and never stored.
Solutions
Solution inventory, install dates, and component membership.
Choices
Metadata plus per-value attribution, so each choice value traces to the components that read and write it.
POWER PAGES · what a site serves to visitors
Web pages
One component per page, per language; the page-template pointer, the components the page embeds, and the page's own JavaScript parsed for Power Pages Web API calls: the table from the route, written columns from the payload, read columns from the query string.
Web templates
The Liquid host. Template extends and includes, snippet references, embedded forms and lists, and Liquid data access as read edges: fetchxml blocks through the same FetchXML reader saved queries use, and direct Liquid record lookups resolved to table and column where the table is written literally. Source is parsed in memory and discarded.
Content snippets
A named Liquid fragment as a node, because it is the heaviest fan-in artifact on a real site; its own outbound references are parsed, recursion-free.
Basic forms
Bound by name to the model-driven form they render, which already carries the column edges, so the site inherits a correct footprint through one hop rather than a second parse. The form's own script is parsed like a page's.
Lists
Bound to each saved query they render, one invocation edge per query, with the list's script parsed for Web API calls.
Advanced forms
The multistep container as a step graph, including condition steps that branch to different next steps, each load-form step joined to the model-driven form it renders.
Server logic
Customer JavaScript published as a site API: the endpoint, its record state, and the web roles that may invoke it. Both a write surface and an egress surface, which is why it is a node rather than site configuration.
Web files
Uploaded files inventoried; JavaScript files downloaded and parsed for the Dataverse calls they make. A file whose bytes could not be read says so, rather than showing an empty footprint.
AI ESTATE · what the ai is built to touch
Copilot Studio agents
Every agent, published or draft: owner, lifecycle state, authentication mode and access policy, authorship, and the licensing status the platform reports. The definitions of its tools and triggers are pulled, walked in memory and discarded: the table a tool is pinned to, whose connection it runs on, where it lands, the flows it is wired to in both directions, the agents it can hand off to, and the knowledge configuration it answers from. Topic bodies are not read.
Agent flows
A flow an agent calls as a tool, its own component type because its caller is an agent deciding at run time rather than a trigger Pathix can name. Read by the same parser as cloud flows, at the same tiers, with the agent-to-flow link reported both from the platform's record and from the agent's definition.
AI Builder models and prompts
Inventory and lifecycle: the model kind resolved through the template catalog, owner, trained and published state, the workflows the platform runs on its behalf, and every cloud flow and agent flow that calls it. Column bindings are not read in this version.
AI prompt columns
The AI writer on a table. Three writes per column (the column and the two run-status and run-details companions the platform mints beside it), one declared read per typed input binding and per grounding filter, the model behind it, its retrieval limit, and whether it runs under the code interpreter. Nothing is read from the prompt text itself.
Knowledge sources
The Dataverse search configuration that declares what an assistant can answer from: a declared read per indexed column, recorded differently for a column whose value can be returned and one that only selects rows; a table-level read where the platform enumerated no columns; the agents joined to the configuration, and the model-driven app when an app copilot owns it.
NOT SHIPPED YET
AI prompts as reusable componentsAI Builder model bindings
For evaluators

Want the per-surface DOES / DOES NOT matrix?

Pathix coverage is documented in detail in a per-surface technical brief: what each parser handles, where the boundaries are, and the roadmap label for every gap. Available on request to evaluators with a real Pathix conversation in flight.

Email brian@pathix.appBook a demo

See the coverage on your environment.

A Pathix scan runs in your subscription, parses every component above, and shows you the writers and dependents of any column inside the first hour.

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