# Chapter 11: ConfigTrack Reference version: 0.8 Reference date: 2026-07-31 Chapter page: https://configcompare.com/reference/11-configtrack/ Full reference: https://configcompare.com/llms-full.txt Chapter index: https://configcompare.com/llms.txt This is one chapter of the ConfigCompare Technical Reference, published by AXImprove Ltd. It is generated from the canonical Markdown source. DO NOT EDIT THIS FILE DIRECTLY. --- ## 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 (https://configcompare.com/reference/01-the-configcompare-platform/). --- ## Related topics - Chapter 01: The ConfigCompare Platform (https://configcompare.com/reference/01-the-configcompare-platform/) - Chapter 03: Core Concepts (https://configcompare.com/reference/03-core-concepts/) - Chapter 04: ConfigCompare (https://configcompare.com/reference/04-configcompare/) - Chapter 06: Snapshots (https://configcompare.com/reference/06-snapshots/) - Chapter 12: ConfigAudit (https://configcompare.com/reference/12-configaudit/) - Chapter 14: Governance & Audit (https://configcompare.com/reference/14-governance-and-audit/)