ConfigTrack

Purpose

ConfigTrack provides structured governance and change management for Microsoft Dynamics 365 Finance & Supply Chain Management configuration changes.

ConfigTrack enables organisations to define, manage, and track configuration changes through customised event workflows, with built-in support for risk assessment, role-based approvals, and regulatory compliance requirements.

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

---

Overview

Configuration change is constant in enterprise ERP environments. Some changes are planned and carefully managed. Others occur operationally or emerge during troubleshooting. Without structured oversight, organisations lose visibility into what changed, why, who approved it, and whether the change was appropriate.

ConfigTrack addresses this governance gap by providing:

• Centralised configuration change events
• Structured task management through change lifecycles
• Risk-based prioritisation and escalation
• Role-based responsibility assignment (RACI matrices)
• Multi-level approval workflows
• Audit-ready change history
• Evidence for compliance and governance activities

---

What ConfigTrack does

ConfigTrack enables organisations to:

• Record configuration changes as structured events with context, rationale, and business impact
• Assess risk based on complexity, user impact, process impact, and likelihood
• Assign responsibilities using RACI matrices to define clear accountability
• Manage approvals through escalation workflows that account for risk and urgency
• Manage tasks across environments by orchestrating configuration changes through DEV → TST → UAT → PROD with sequenced, environment-specific tasks
• Track task progress from creation through completion and closure across the entire deployment lifecycle
• Maintain audit trails for compliance with SOX, J-SOX and internal control requirements
• Generate governance reports for management review and audit activities
• Integrate with ConfigCompare to validate configuration changes against baselines

---

Core concepts

Configuration Events

A Configuration Event represents a planned or observed configuration change.

Events provide the primary organisational unit for change management. Each event captures:

• What configuration is changing
• Why the change is being made
• Who initiated and approved the change
• When the change was made and when it was approved
• Expected impact on users and business processes
• Whether the change aligns with approved configuration standards

Events move through a defined lifecycle: Open → In Progress → Complete → Closed.

---

Change tasks

Tasks represent work that needs to happen as part of a configuration change event.

A single event may spawn multiple tasks assigned to different users or teams, often sequenced across the deployment lifecycle:

• Configuration implementation tasks (for example, “DEV: Implement new GL account structure”)
• Environment-specific deployment tasks (for example, “TST: Promote configuration to Test environment”)
• Testing and validation tasks (for example, “UAT: User acceptance testing”)
• Approval and review tasks (for example, “UAT: Business sign-off”)
• Production deployment tasks (for example, “PROD: Deploy configuration”)
• Documentation tasks
• Post-change verification tasks

Tasks can be structured to orchestrate changes through multiple environments in sequence, for example:

1. DEV implementation
2. TST validation
3. UAT testing
4. UAT business signoff
5. PROD deployment

Each task has ownership, due dates, environment context, and completion status. The event cannot close until all associated tasks are complete. This enforces structured progression of changes through the deployment pipeline and prevents premature advancement to the next environment.

ConfigTrack task orchestration supports Application Lifecycle Management by making the entire change journey, from development through production, visible, planned and controlled.

---

RACI matrices

ConfigTrack uses RACI (Responsible, Accountable, Consulted, Informed) matrices to define clear roles in configuration change governance.

• Responsible: The person or team executing the change
• Accountable: The person authorising and accepting responsibility for the change
• Consulted: Stakeholders whose input is required during the change
• Informed: Stakeholders who need visibility into the change but do not need to approve

RACI assignments give every role in the governance process a clear statement of its responsibility and decision-making authority.

---

Risk assessment

ConfigTrack assesses configuration change risk across multiple dimensions:

• Complexity: Technical difficulty and scope of the change
• User Impact: Number of affected users and severity of impact
• Process Impact: Effect on business processes and workflows
• Likelihood of Issues: Historical patterns and technical risk factors

Risk assessment is automated but can be overridden by governance personnel when business context warrants different prioritisation.

---

Priority and escalation

Configuration changes are prioritised based on assessed risk and business urgency.

High-risk changes receive elevated approval requirements and senior review.

Lower-risk changes follow simpler approval paths.

Escalation rules account for:

• Change complexity and scope
• Number of affected users
• Regulatory or compliance implications
• Timeline pressures
• Cross-company or cross-system impact

---

Approval workflows

ConfigTrack provides multi-level approval workflows that adapt to change risk and context.

Approval workflows may require:

• Functional Consultant sign-off on technical correctness
• Business Analyst approval of process implications
• Compliance Officer review for regulatory requirements
• Department Manager approval for operational impact
• System Administrator final authorisation

Approval chains route changes to the right stakeholders for review before implementation.

---

Configuration Governance through ConfigTrack

ConfigTrack supports organisations in achieving structured Configuration Governance.

Change documentation

Every configuration change is documented with clear context, rationale, and expected outcomes.

Documentation becomes part of the permanent audit trail and supports:

• Root cause analysis when issues occur
• Evidence for regulatory audits
• Knowledge transfer to new team members
• Capacity planning based on historical change patterns

Compliance and audit

ConfigTrack supports compliance frameworks including:

• SOX (Sarbanes-Oxley) internal control requirements
• J-SOX (Japan) governance and audit requirements
• Internal audit procedures
• Regulatory compliance evidence

Configuration events cannot be deleted or materially modified once closed, which preserves evidence integrity.

Role-based access control

ConfigTrack implements three security roles with escalating permissions:

• Viewer: Can view configuration events and reports but cannot create or modify events
• User: Can create events, manage associated tasks, and approve events within their scope
• Manager: Can approve high-risk events, configure approval workflows, and access governance reports

Role-based access supports appropriate delegation of authority while maintaining oversight.

---

ConfigTrack and ConfigCompare

ConfigTrack and ConfigCompare serve complementary purposes.

Aspect	ConfigCompare	ConfigTrack
Primary Purpose	Deterministic Comparison of configuration	Governance and change management
Focus	What changed and Differences	Why it changed and whether it was approved
Evidence	Point-in-time Snapshots and comparisons	Event records and approval workflows
Integration	Captures baseline configurations	Validates changes against baselines
Audit Support	Configuration history and Differences	Change approval and authorisation trail
Compliance Evidence	Configuration state evidence	Change control and governance evidence

Integrated workflow:

1. An organisation identifies a need for configuration change
2. A ConfigTrack event is created with risk assessment and RACI assignments
3. Stakeholders review and approve the change through ConfigTrack workflows
4. The change is implemented in the D365 environment
5. A post-change ConfigCompare Snapshot is captured and compared to the pre-change baseline
6. The comparison validates that the change was implemented as intended
7. The ConfigTrack event is closed with evidence of change completion and validation

This integrated approach provides both evidence of proper governance and factual evidence of what actually changed.

Comparison results themselves carry no native review state. Marking a finding as reviewed and tracking its remediation are ConfigTrack capabilities, recorded against the event rather than against the comparison.

---

Typical governance scenarios

Planned configuration change

An organisation plans a configuration change to support a new business process.

1. A System Administrator creates a ConfigTrack event describing the change
2. Risk assessment automatically flags the change as medium-risk
3. The event is escalated to the Functional Consultant and Business Analyst for review
4. A test implementation occurs and is validated
5. The change moves to UAT for business user acceptance
6. Upon approval, the change is implemented in production
7. A post-change ConfigCompare Snapshot validates the change
8. The event is closed with all evidence attached

---

Configuration Drift investigation

An organisation discovers unexpected Configuration Drift in production.

1. ConfigCompare identifies the Difference
2. A ConfigTrack event is created to investigate and resolve the drift
3. Root cause analysis determines whether the change was authorised
4. If unauthorised, the configuration is corrected and documented
5. If authorised, the event is updated with missing approval documentation
6. The event is closed with evidence of resolution

---

Compliance review

An external auditor requests evidence of configuration controls.

1. ConfigTrack reports show all configuration changes over the audit period
2. Each change includes approval workflows and authorisation evidence
3. Events that appear high-risk receive special scrutiny
4. ConfigCompare Snapshots provide factual evidence of what existed at specific points in time
5. Combined evidence demonstrates compliance with configuration control requirements

---

Business outcomes

Typical reasons for adopting ConfigTrack include:

• Structured Change Management: Replace ad-hoc change processes with defined workflows
• Visibility: Know what changed, why, and whether it was approved
• Reduced Risk: Assess and escalate high-risk changes appropriately
• Reduced Costs: Prevent rework and failed changes through structured approvals
• Compliance Evidence: Support SOX, J-SOX, and audit requirements
• Operational Confidence: Understand the governance controls around configuration
• Faster Approvals: Route changes efficiently through appropriate approval chains
• Knowledge Capture: Document rationale and impact for future reference
• Root Cause Support: Reference historical changes when investigating issues

---

Relationship to the platform

ConfigTrack 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 06: Snapshots
• Chapter 12: ConfigAudit
• Chapter 14: Governance & Audit