ConfigAudit

Purpose

ConfigAudit provides event-level audit and change tracking for critical configuration areas in Microsoft Dynamics 365 Finance & Supply Chain Management.

ConfigAudit captures create, update and delete events on designated Data Entities, maintaining a granular audit trail of changes to the configuration areas an organisation cares deeply about, without bloating the ERP transactional database.

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

---

Overview

Configuration Governance (ConfigCompare) and transaction-level digital signatures (Electronic Signature) represent two extremes of audit coverage in ERP systems.

ConfigCompare captures point-in-time Snapshots of configuration, revealing what exists and how it differs, but missing transient changes that occur between Snapshots.

Electronic Signature provides transaction-level approval and signature, but only for the highest-control scenarios and most regulated companies.

ConfigAudit fills the middle ground: continuous, event-level audit of the critical configuration areas that matter to an organisation.

Rather than waiting for the next configuration Snapshot or requiring full transaction signatures, ConfigAudit tracks changes to specific Data Entities in real time, creating an immutable audit trail for the critical configuration areas an organisation monitors most closely.

---

What ConfigAudit does

With ConfigAudit, organisations can:

• Define audit scope by selecting critical Data Entities for continuous monitoring
• Capture all changes through a custom business events endpoint that intercepts create, update and delete operations
• Access recent data via a dedicated inquiry screen within D365 for quick queries on the last 3 days of changes
• Retain complete history in user-defined Azure tables for long-term audit, analysis, and compliance
• Query in multiple formats tailored to different analytical and compliance questions
• Maintain performance by keeping the D365 transactional database clean and responsive
• Support audit evidence for regulatory, compliance, and internal control requirements

---

Three tiers of audit and control

ConfigAudit operates within a three-tier governance model.

Tier	Purpose	Scope	Use Case
ConfigCompare	Configuration Governance	Configuration Snapshots	“What configuration exists and how does it differ?”
ConfigAudit	Event-level configuration area audit	Create, update and delete events on Data Entities	“What changed within critical configuration areas and when?”
Electronic Signature	Transaction-level approval and signatures	Individual transactions	“Which transactions were explicitly approved?” (highest control)

Each tier serves organisations with different governance maturity and regulatory requirements.

Many organisations begin with ConfigCompare. ConfigAudit extends event-level audit coverage to critical configuration areas. Electronic Signature (D365 native capability) serves organisations requiring transaction-level digital signatures.

---

Core concepts

Critical configuration areas

ConfigAudit focuses on critical configuration areas: the areas an organisation must track for audit, compliance, or governance purposes.

Examples include:

• General ledger accounts (account types, posting profiles, validation rules)
• Bank routing and payment configuration
• Tax configuration on transactional records
• Intercompany transaction parameters
• Inventory parameters (costing methods, reservation policies)
• Pricing tables (product pricing, customer-specific pricing, promotion rules)
• Vendor master data (bank accounts, payment terms, address changes)
• Customer master data (credit limits, payment terms, invoice routing)

The vendor and customer examples widen tracking beyond configuration into master data; the considerations that govern that decision are described in the How wide should tracking go? section.

These areas sit outside the Snapshot-based configuration scope described in Chapter 04: ConfigCompare; ConfigAudit monitors them at event level.

---

How wide should tracking go?

Audit scope is not technically limited to configuration. Any designated Data Entity can be monitored, including master-data-style entities such as customers or vendors. This is a common requirement when organisations want changes made in the background to surface immediately.

Two considerations govern how wide to go:

• Performance: capture cost grows with the size and change rate of the monitored entity.
• The review test: a monitored area is only worth monitoring if someone will actually review its changes. If no one would, it is transactional or document data and should not be tracked.

The recommended scope remains critical configuration areas. Wider tracking is a deliberate decision measured against these two tests; the same test applies to ConfigCompare Snapshot scope (Chapter 04: ConfigCompare).

---

Data Entities and business events

ConfigAudit uses a custom business events endpoint to capture create, update and delete events on Data Entities.

Data Entities are preferred over tables because they:

• Represent logical business concepts rather than physical database structures
• Provide semantic meaning (for example, “Vendor” instead of “VendTable”)
• Support multiple source systems and integration patterns
• Are the standard D365 integration layer

ConfigAudit intercepts create, update and delete operations on monitored Data Entities and records:

• What changed (field and previous/new values)
• When the change occurred
• Who initiated the change (user context)
• System context (legal entity, environment, etc.)

Read operations are not captured.

---

Local retention and inquiry

ConfigAudit maintains dual storage architecture:

• Azure tables: hold the complete audit history
• D365 local tables: hold only the most recent 3 days (the “tail”) for fast queries and offline access

Local D365 retention enables:

• Fast queries within D365 itself for immediate review without external calls
• Dedicated inquiry screen for users to search and review recent changes
• Performance for common queries on recent activity
• Offline access if connectivity to Azure is temporarily unavailable

All data flows to Azure tables in real time, so the audit history in Azure is complete. D365 tables are purged after 3 days, keeping the transactional database lean while maintaining complete audit coverage in Azure.

---

Azure Table Storage and analysis

All audit data is pushed to user-defined Azure tables in real time, providing complete audit history independent of D365. All ConfigCompare artefacts (Snapshots, Comparisons and audit history) are stored in Azure Storage owned and controlled by the customer. AXImprove holds no customer data; data ownership remains with the customer at all times.

Storage architecture

ConfigAudit maintains a canonical audit record alongside multiple materialised read models, each optimised for specific query patterns and analytical questions. Rather than forcing all users to query a single canonical table and perform custom joins, ConfigAudit maintains multiple denormalised copies, each structured for a specific audience perspective.

Example perspectives include:

• By date: For daily reconciliations and compliance reviews
• By data entity or table: For business process owners and data stewards
• By record: For transaction-level traceability (for example, “show me all changes to vendor ABC123”)
• By column: For understanding what specific fields changed across all records
• By user: For access audits and user activity analysis
• By company: For consolidated multi-company governance
• By operation: For tracking create, update and delete patterns and identifying deletions

Analysis and compliance

Azure storage enables:

• Complete audit history without time limits or D365 database bloat
• Optimised queries across different analytical perspectives without custom transformations
• External analysis tools for audit firms, compliance teams, and analytics platforms
• Long-term trend analysis of changes within critical configuration areas over time
• Regulatory evidence that persists independent of D365 lifecycle
• Separation of concerns: D365 handles recent queries, Azure handles historical analysis

External analysis applies to ConfigAudit audit data; ConfigCompare Comparison results are reviewed within the product.

Organisations define which perspectives to maintain and how data flows to Azure, supporting their specific compliance and analytical requirements.

---

Transient change capture

ConfigAudit solves a fundamental gap in configuration-based audit approaches.

The Snapshot Blind Spot

ConfigCompare identifies Differences between Snapshots. But changes that are made and then reverted before the next Snapshot are invisible to ConfigCompare.

Consider a vendor bank account change scenario:

1. Snapshot 1 is captured on Monday. Bank account is “ABC123”.
2. Tuesday 2am, the bank account is changed to “XYZ789”.
3. Tuesday 3am, the account is changed back to “ABC123”.
4. Snapshot 2 is captured on Wednesday. Bank account is “ABC123” (unchanged).

ConfigCompare sees no change. The configuration was “ABC123” at both Snapshots.

But ConfigAudit captures both the change and the reversion, creating a complete record of what happened when.

Operational error detection

In the case of an accidental error:

• Identify which transactions were affected
• Investigate whether payments went to wrong accounts
• Provide evidence that the incident occurred and was corrected
• Implement preventive controls

Fraud detection

The same capture applies to intentional misconduct:

• An employee deliberately changes a vendor bank account to their own account
• Processes a payment to the fraudulent account
• Reverts the change before the next comparison or audit
• ConfigCompare would show no Difference
• ConfigAudit captures the full change history, exposing the fraud

ConfigAudit captures the complete change history that exposes both operational errors and intentional changes made to hide unauthorised transactions.

---

ConfigAudit and ConfigCompare

ConfigAudit and ConfigCompare serve complementary purposes and are often used together.

Aspect	ConfigCompare	ConfigAudit
What it tracks	Configuration	Critical configuration areas (designated Data Entities)
How it tracks	Point-in-time Snapshots	Continuous event stream
Granularity	Configuration table level	Field-level create, update and delete changes
Timeline	Snapshot intervals (for example, daily)	Real-time
Storage	Snapshots + comparisons in D365	3-day local retention plus full history in customer-controlled Azure storage
Audit question	“What configuration exists?”	“What changed within critical configuration areas, and when?”

Integrated workflow:

1. An organisation monitors both configuration (ConfigCompare) and critical configuration areas (ConfigAudit)
2. ConfigCompare Snapshots reveal configuration baselines and drift
3. ConfigAudit events reveal day-to-day changes within critical configuration areas
4. Together they answer: “What was configured, what changed, when, and whether it matches our expectations?”

---

Business scenarios

Vendor master data monitoring

An organisation wants to detect any changes to vendor bank accounts, payment terms, or tax registration numbers in real time.

1. The Vendor Data Entity is configured for ConfigAudit monitoring
2. When a vendor record is updated, ConfigAudit captures the change
3. Users can query the inquiry screen to see recent vendor changes
4. Finance and Accounts Payable teams use the Azure data for compliance and analytics
5. External auditors can review vendor master changes as part of audit procedures

---

General ledger account compliance

A regulated company requires tracking of all changes to GL account properties (posting profiles, account types, validation rules).

1. The GL Account Data Entity is monitored by ConfigAudit
2. Every change is recorded with user, timestamp, and previous/new values
3. Finance managers use the inquiry screen for routine oversight
4. Auditors access Azure tables for evidence of GL control compliance
5. High-risk changes (for example, to revenue accounts) trigger additional review workflows

---

Transient error detection

An operational incident occurs when critical parameters are accidentally changed and reverted before the next Snapshot.

1. ConfigAudit captures both the error and the correction
2. ConfigCompare shows no Difference (reverted to original state)
3. Operations teams use ConfigAudit evidence to identify which transactions were affected
4. Investigation teams determine whether the incident caused downstream problems
5. Corrective actions are implemented with complete evidence trail

---

Regulatory and audit evidence

An external auditor requests evidence of changes to critical configuration areas over a fiscal year.

1. ConfigAudit provides a complete audit trail
2. Data is queried from Azure tables in formats suitable for audit analysis
3. Evidence includes who changed what, when, and previous/new values
4. The audit team can independently analyse trends, patterns, and control effectiveness
5. The organisation demonstrates governance of critical configuration areas

---

Business outcomes

Organisations adopt ConfigAudit to:

• Audit Readiness: Provide evidence of controls over critical configuration areas
• Incident Investigation: Determine whether changes within critical configuration areas explain unexpected operational behaviour
• Incident Cost Reduction: Resolve issues faster by identifying root causes quickly
• Compliance Evidence: Support regulatory requirements for change tracking within critical configuration areas
• Risk Reduction: Expose unauthorised or erroneous changes within critical configuration areas
• Performance: Monitor changes without bloating the D365 database
• Analytical Depth: Understand patterns and trends in changes within critical configuration areas over time
• Governance Coverage: Extend audit coverage between configuration Snapshots
• Control Assurance: Demonstrate that critical configuration areas are properly controlled

---

Relationship to the platform

ConfigAudit operates alongside the other platform components, each with a single clearly defined responsibility; the full component list is described in Chapter 01: The ConfigCompare Platform.

---

Related topics

• Chapter 01: The ConfigCompare Platform
• Chapter 03: Core Concepts
• Chapter 04: ConfigCompare
• Chapter 11: ConfigTrack
• Chapter 14: Governance & Audit