Chapter 05 · Comparison Engine

Technical reference · Chapter 05

Comparison Engine

Purpose

The ConfigCompare comparison engine performs Deterministic Comparison between two Snapshots.

The engine is the factual core of the ConfigCompare Platform. Every governance capability described in this reference (Rulesets, AI Insights, Alerts, ConfigTrack workflows, Upgrade Analysis and enterprise orchestration) is focused on the output of the engine.

This chapter describes concepts and behaviour; step-by-step operating guidance sits outside this reference.

Deterministic by design

A Deterministic Comparison means the result is produced by defined comparison logic. It is not guessed, inferred, or generated by an AI model.

Given the same two Snapshots, the engine will always produce the same result.

Configuration Governance requires evidence. A governance platform must be able to show exactly what it compared and what it found, and produce the same answer every time the question is asked.

The engine is separated from interpretation. It identifies facts; Rulesets, users, organisational processes and AI-assisted capabilities determine what those facts mean and how they should be acted upon.

Comparison inputs

Every comparison takes two Snapshots as input.

The two Snapshots may come from:

Two different environments (for example UAT and PROD).
Two different companies (legal entities), including many companies against one reference company.
The same environment or company at two points in time.
Before and after an upgrade.

The scope of a comparison is defined by the configuration Tables and Data Entities captured within the Snapshots, typically established through the curated Configuration Catalogue and extended for ISV, bespoke and customer-specific configuration areas (see Chapter 04: ConfigCompare).

Table-level comparison

ConfigCompare is designed to compare what Dynamics 365 actually is at table and configuration level, rather than only what an application programming interface or Data Entity exposes.

Tables are the only first-class citizens that can represent configuration data in D365 F&SCM. Views, Data Entities, and even forms are all curations of some subset of the data held in tables. A field left out of an entity or form still exists at table level, and still drives application behaviour.

ConfigCompare can capture from both Tables and Data Entities, but because comparison is grounded in tables, coverage is not limited by what entity design chose to expose. This allows deeper coverage than approaches limited to entity design alone.

Data Entity support

Data Entities are one of the two capture sources supported by the engine, alongside Tables.

Data Entities provide semantic, business-level representations of configuration and enable supported export scenarios, including Data Management Framework (DMF) package generation used by ConfigMigrate.

Coverage is defined by the Configuration Catalogue rather than by Data Entity availability: where table-level or metadata-level comparison is required, the engine operates beyond Data Entity level.

What the engine identifies

Depending on the comparison type and configuration of the comparison, the engine identifies:

Differences: configuration that varies between the two Snapshots.
Matches: configuration that is identical between the two Snapshots. Matches are equally important governance findings when environments should differ but do not (see Chapter 03: Core Concepts).
Structural changes: metadata-level changes, in upgrade and Metadata Comparison scenarios.

Two dimensions of comparison

Comparison results are reported across two orthogonal dimensions at every level of detail:

Structure: schema-level comparison covering which tables and columns are present, and how their definitions differ.
Data: row-level and field-level comparison of the configuration values themselves.

A table can be structurally identical but hold different data, hold identical data within a changed structure, or differ in both. Reporting the two dimensions separately allows each finding to be assessed on its own terms.

Result vocabulary

Comparison results use a consistent vocabulary at every grain (company, table, row and field):

Same AB: present in both Snapshots and identical (a Match).
Diff AB: present in both Snapshots but different (a Difference).
Only A: present only in Snapshot A (for example, a deletion when A is the older Snapshot).
Only B: present only in Snapshot B (an addition).
Not present: absent from both Snapshots. Not present is distinct from Same AB: a value absent from both Snapshots is not the same as a value identical in both.

Because the same vocabulary appears at every level, users learn the result grammar once and apply it everywhere, from a whole comparison down to a single field.

Reference resolution

Configuration values are often stored as enumeration values or record references that are not meaningful on their own.

When presenting field-level results, ConfigCompare resolves enumeration and foreign-key fields to their human-readable meaning and shows it alongside the raw stored value; for example, a stored value of 0 resolved to “No”, or a stored field identifier resolved to that field’s label.

This resolution makes table-level comparison readable for functional consultants as well as technical staff, and is a key benefit of comparing at table level rather than only at Data Entity level.

Binary and BLOB configuration

Some configuration is stored as binary objects (BLOBs) rather than as individual fields; approval workflow definitions are a common example.

The engine compares binary configuration by content signature (hash). A change to a BLOB is detected deterministically, but its contents are not decoded: the engine reports that the binary value differs, not what changed inside it. Detailed inspection currently requires opening the configuration in both systems and reviewing it manually.

Structured pre-processing that unpacks BLOBs of known formats so their contents become comparable is a planned enhancement (see Chapter 26: Roadmap).

Structural change detection

The engine can identify structural changes as part of upgrade and Metadata Comparison scenarios.

Structural changes may include table changes, column additions, column removals, data type changes, size changes, label changes, and other metadata-level changes depending on the scope of the comparison.

Metadata Comparison scans all persisted application tables rather than only the preselected configuration scope; this capability is described in Chapter 16: Upgrades.

Comparison at scale

The engine is designed to operate at enterprise configuration scale. In a Contoso-scale reference environment, comparison of captured Snapshots has completed in approximately 30 seconds. Actual timings depend on selected scope, environment performance, infrastructure, concurrency and workload conditions. Reference benchmarks are described in Chapter 06: Snapshots.

Comparison output

Comparison output can support:

Detailed review.
Governance evidence.
AI Insights.
Alerts and notifications.
Ruleset classification.
Ownership assignment.
Support triage.
Upgrade impact assessment.

The output is consumed by the rest of the platform: Rulesets classify results and assign Responsibility (Chapter 08), AI Insights explain results (Chapter 09), and Monitoring & Alerts escalate results (Chapter 10). The Deterministic Comparison result always remains the authoritative source of truth.