PathixDataverse Forensics
How it works · Coverage model

What writes to your columns. Where the gaps are.

Pathix scans your D365 environment across forty-two component types 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, and the tiers are never averaged into one score: the weakest shows as plainly as the strongest.

●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.

Three confidence levels, never averagedA specimen tray on grid paper holds a cloud flow block, two plugin blocks and one column, Credit Limit. The cloud flow's solid wire reaches the column, labeled Deterministic. A plugin's dashed wire, marked with a star, reaches the same column at its own point, labeled AI-derived. The other plugin's write fades out over bare paper past the tray with a question mark: its target column is not resolved, labeled Unresolved.PLGPLGFLW✦?DeterministicAI-derivedUnresolvedCredit Limitaccount.creditlimit
Three confidence levels, never averagedA specimen tray on grid paper holds a cloud flow block, two plugin blocks and one column, Credit Limit. The cloud flow's solid wire reaches the column, labeled Deterministic. A plugin's dashed wire, marked with a star, reaches the same column at its own point, labeled AI-derived. The other plugin's write fades out over bare paper past the tray with a question mark: its target column is not resolved, labeled Unresolved.PLGPLGFLW✦?1234
  1. Deterministic
  2. AI-derived
  3. Unresolved
  4. Credit Limitaccount.creditlimit
Book a demoSecurity architecture
Pathix in two minutes
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.

What a scan costs your Dataverse environment, measured →

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). Never record values, audit log payloads, or embedded literals from execution traces.
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.

42 component types 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 to a plugin type, service endpoint or webhook, and the shape of secure and unsecure configuration), plus the compiled assembly's 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 columns
The Power Fx formula: the platform engine as the writer of its own column, and a read for each column the formula uses.
Calculated columns
The legacy XAML formula: the platform engine as the writer of its own column, and a computation read for each column the formula cites.
Rollup columns
The aggregated column on the related table as a computation read, a filter read for each condition, and the aggregate operator.
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
The Service Bus, Event Hubs and Event Grid endpoints a plugin step routes to. Contract metadata only: endpoint URL, auth scheme type and whether a key is present. SAS keys and connection-string secrets are dropped at the wrapper boundary and never stored.
Webhooks
The HTTP endpoints a plugin step routes to. Contract metadata only: URL, auth scheme type, whether a key is present, and header names. Header values and secrets are dropped at the wrapper boundary and never stored.
Virtual table data providers
The registration that runs every read and write against a virtual table: which virtual tables each provider serves and which operations it implements, so a virtual table names the code that writes it. Which columns an operation writes is decided by the external system, so it isn't reported.
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.
Site chatbots
The Copilot Studio agent a site's chatbot points at, recorded as part of the site with an edge to that agent, so an agent reachable from a public site shows up as a channel. Who can reach it is the agent's own authentication setting, recorded on the agent.
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. Topics are read only for the cloud flows they call; their own writes, conditions and variables 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.

Also read on every scan, though neither is a component type: 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.

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.π