Workday change controls — smarter, simpler with Configuration Change Tracker

Contributor: Kenny Schreiner, Workday Principal Product Leader.

Released in Workday 2024R2, Configuration Change Tracker helps simplify audit and compliance — bringing more clarity and control to your process. Originally built to help implementers track config changes across tenants, Configuration Change Tracker is a native Workday tool that also supports internal controls — helping monitor and assess key changes for audits and regulatory requirements. This article, written in coordination with Workday product management, introduces a refreshed, native approach to Workday configuration change controls using Configuration Change Tracker, helping deliver benefits like:

• 100% native Workday (developed and supported by Workday).
• Zero custom reports.
• Improved reporting clarity.
• Easier to audit.

Organizations use varying approaches to configuration change management in Workday, but many are highly manual. There are several industry-leading practices for configuration change management, but our approach can bring them together — using risk-based scoping, audit tags, and custom reports to help monitor task-driven changes within the tenant. 

While prior configuration change control approaches were effective, they relied on multiple custom reports that added complexity — requiring significant effort to maintain completeness and accuracy for audit standards. In some cases, the control process became more burdensome than the risk itself, prompting Workday users to rethink the cost of managing change.

To remedy this, Configuration Change Tracker supports a refined approach based on three principles:

1. Limit scope using thoughtful risk assessments.
2. Utilize (or continue utilizing) audit tags for changes to business processes, custom reports, user-based security groups and integration systems.
3. Leverage native Configuration Change Tracker to help monitor changes affected via task execution or web services.

Configuration Change Tracker offers a smarter way to help track configuration changes in Workday. Originally built to reduce the burden on implementers, it automates the process of capturing tenant changes for migration — helping free teams from manual tracking. And with Workday 2025R2, Configuration Change Tracker takes it a step further: report outputs can now be used to automatically generate configuration packages for future deployments.

This innovative update comes with a few important considerations — here’s what to know before putting it into practice.

• Configuration Change Tracker reports only on changes tied to migratable implementation types— Workday-defined objects that can be moved between tenants. If a changed instance doesn’t fall under a supported type, it won’t be captured in the report or eligible for migration. While this may sound limiting, it rarely poses an issue. Our risk assessment and scoping strategy are designed to account for these cases — so nothing important slips through the cracks.
•  Configuration Change Tracker doesn’t support object lineage — it can only capture direct changes. That means downstream behavioral changes typically aren’t reported. To close that gap, we continue to rely on audit tags whenever possible, as they do support object lineage. For this reason, we recommend using Configuration Change Tracker only when audit tags can’t effectively track the change.
• Configuration Change Tracker captures the object instance changes within a tenant —typically up to 10 million per report. Keep in mind: a single configuration update can trigger multiple instance changes which are tracked in the output. This level of detail supports more precise scoping and planning during implementation.
• Configuration Change Tracker groups changes by primary instance—helping make reporting clearer and easier to navigate. Each report allows you to drill into the full audit trail, including the primary object, timestamp, effective moment, attribute changes, relationships, new and old values, and the account that made the change. This structure helps bring added clarity and context to each configuration update.

Step 1: Scope audit-taggable objects through risk assessment

Start by using audit tags to monitor changes to objects like business processes, custom reports, integrations, and user-based security groups (as of Workday 2025R1). Configuration Change Tracker should only be used when audit tags can’t effectively track changes.

Conduct a risk assessment using agreed-upon criteria to help identify which objects should be tagged and audited. Clearly document your scope and set up audit tags using Workday’s guidelines. This step helps rationalize the configuration change control process while confirming the scope is well-documented.

Step 2: Assess non-audit-taggable implementation types

Each configuration change is linked to a Workday implementation type. Our approach scopes out taggable objects first, then assesses non-taggable types to help identify high-risk changes that require monitoring.

Here’s how:

• Get the full list of implementation types using the Implementation Type Details report.
• Filter out taggable object types (e.g., business process definitions, custom reports, integration systems, and user-based security groups). Changes to these should use audit tags.
• Review non-migratable types to confirm they don’t require monitoring. This helps confirm audit documentation is complete.
• Prioritize the remaining migratable types through a risk assessment aligned to your control objectives. Focus on the imperative few and document the rationale.
• Group similar implementation types by area (e.g., function, owner) to help simplify reporting and improve accountability.

Step 3: Define your Change Tracker reports

Configuration Change Tracker helps you build reports using tailored parameters. For each group of implementation types, create a report that includes:

• User account.
• Timeframe.
• Implementation type and hierarchy.
• Web services toggle.

Report names default to [account name]-[timestamp] but can be renamed. Each run is saved in the Configuration Change Tracker Report History and can be re-run with updated parameters — adding version control and improving auditability.

Step 4: Run or rerun the report to review changes

Use the Configuration Change Tracker Report History to select and rerun a saved report with updated moments. Reports split changes into:

• Ready to migrate (new and modified configurations).
• Not Ready to migrate (e.g., deletions or objects not migrated individually).

Review both groups. All configuration changes — including new, modified and deleted instances — can be relevant to control objectives.

Step 5: Review the validity of configuration changes

Select “View Changes” to see detailed updates to attributes and relationships. The report includes:

• Old and new values (when available).
• User and timestamp data.
• Export reports to spreadsheet or PDF for deeper review or reconciliation. For SOX environments, consider capturing screenshots of change totals to support evidence of completeness.

Originally designed to support tenant migration, Configuration Change Tracker will soon allow direct package migration (starting in Workday 2025R2). But you can benefit from it today by pairing it with a risk-based control process.

With thoughtful planning and follow-through, Configuration Change Tracker can strengthen your audit and compliance practices — making configuration change monitoring more effective.

Follow these five steps to build an effective, native Workday control process for monitoring configuration changes — grounded in industry-leading practices. Contact us to explore how PwC can support your Workday journey with sustainable, risk-aligned security and compliance practices.