TL;DR: Key Takeaways
- Why the Entra provisioning engine disables accounts that leave scope, even when the worker was never terminated
- Where the SkipOutOfScopeDeletions flag lives, and why it isn’t in the admin portal
- How to trace an unexpected disable in the Microsoft Entra provisioning log instead of rewriting the filter
- How to write a scope filter that handles a null source value without relying on undocumented behavior
- Why a scope-exit cleanup in Active Directory becomes a disabled cloud identity after the next Entra Connect cycle
Automated identity provisioning from Workday does exactly what it’s built to do: create accounts on hire, update attributes when workers change roles, and disable accounts on termination. Once it’s working, most organizations have little reason to revisit it.
In many enterprises, Workday provisions accounts into on-premises Active Directory through the Microsoft Entra provisioning agent, and Entra Connect synchronizes those accounts to Entra ID. The account lifecycle is determined in Active Directory; Entra reflects the result. Hold onto that distinction: the behavior described below occurs in the Workday-to-AD provisioning app, not during cloud synchronization.
Provisioning also carries defaults that most organizations never explicitly chose. Those defaults stay invisible until the business asks the system to behave differently from its original design.
We encountered one of those defaults while helping a client prepare for a large, time-boxed workforce transition. The same behavior can affect any organization using scope-based provisioning.
The Situation
The client was preparing for a time-sensitive workforce transition involving several thousand employees on a single effective date. Under normal conditions, Workday would update each worker’s status and the provisioning app would disable the corresponding Active Directory account.
The business needed the ability to delay that action for one defined cohort if the transition timeline changed. Those accounts had to remain enabled without interrupting provisioning for the rest of the workforce.
A Plan That Needed More Than a Configuration Change
The plan was straightforward. HR would assign a unique termination reason code to the affected workers. The provisioning scope filter would recognize that value and exclude those workers from normal termination processing.
Before building any filter logic, we validated the data path.
We worked with HR to identify exactly where the termination reason lived within Workday. Once we found the field, we mapped it to an unused Active Directory attribute. We weren’t building the solution yet; we were confirming that the value reached Active Directory exactly when we expected.
In our sandbox, we terminated a test worker using the flagged reason code and confirmed that the attribute populated correctly. Only then did we build the scope filter.
Confirming the attribute populated correctly, in isolation, before designing the filter. This ordering narrowed the diagnosis later.
That sequencing paid off. We built the exclusion logic around the validated attribute and ran the only test that counted: terminate a worker with the flagged reason code and confirm the account stayed enabled.
The account disabled anyway.
Reading the Log Instead of Guessing
Because we had already validated the data path, we knew the attribute mapping wasn’t the problem. It would have been easy to assume the filter was wrong and start rewriting it. Instead, we examined the provisioning log. The filter had worked exactly as designed: the worker evaluated as out of scope. The disable came from somewhere else. It wasn’t triggered by termination processing at all; it came from a separate scope-exit cleanup action that runs whenever a worker leaves an application’s provisioning scope.
That sequencing paid off. We built the exclusion logic around the validated attribute and ran the only test that counted: terminate a worker with the flagged reason code and confirm the account stayed enabled.
The account disabled anyway.
Reading the Log Instead of Guessing
Because we had already validated the data path, we knew the attribute mapping wasn’t the problem. It would have been easy to assume the filter was wrong and start rewriting it. Instead, we examined the provisioning log. The filter had worked exactly as designed: the worker evaluated as out of scope. The disable came from somewhere else. It wasn’t triggered by termination processing at all; it came from a separate scope-exit cleanup action that runs whenever a worker leaves an application’s provisioning scope.
The provisioning log traced the disable to the scope-exit cleanup action, not to termination processing. Different trigger, different part of the pipeline.
The Hidden Default: SkipOutOfScopeDeletions
When a worker exits scope, the provisioning engine disables the target account as a cleanup action, regardless of whether the worker was terminated. In this architecture, the target is the on-premises Active Directory account, and Entra Connect then synchronizes that disabled state into Entra ID, so a scope-exit cleanup in AD becomes a disabled cloud identity during the next synchronization cycle.
The setting that controls this behavior, SkipOutOfScopeDeletions, isn’t exposed in the administration portal. It lives in the provisioning application’s secrets and has to be configured through Microsoft Graph, a procedure Microsoft documents in Skip deletion of out of scope users. When the setting is absent, the provisioning engine falls back to its default behavior and disables anything that leaves scope. That was exactly what we observed.
We added SkipOutOfScopeDeletions, set it to true, and repeated the test. The flagged workers remained out of scope but were left unchanged and enabled in Active Directory. Entra Connect preserved that state in Entra ID.
How the Entra Scope Filter Handles NOT EQUALS Against a Null Value
Solving the scope-exit behavior exposed a second issue. The filter needed to include every worker except those assigned one specific termination reason code, and the vast majority of active employees had no termination reason at all. That raised a question: how would the provisioning engine evaluate NOT EQUALS against a null value? The behavior wasn’t documented, and an incorrect assumption could either fail to protect the flagged workers or unintentionally remove active employees from scope.
[REASON_CODE] is a placeholder for a client-specific value, redacted here. Splitting one ambiguous condition into two explicit ones removes the dependency on undocumented null handling.
Rather than relying on undocumented null handling, we removed the ambiguity entirely. We created two explicit filter paths: workers with no termination reason remained in scope, and workers with a populated termination reason remained in scope unless the value matched the flagged code. Every worker matched exactly one tested path, and the provisioning engine never had to evaluate an undocumented edge case.
With the scope-exit cleanup disabled and the filter split in two, each cohort has a tested, predictable outcome.
Why This Matters Beyond One Event
Provisioning defaults usually surface at the edges: workers leaving scope, missing source values, cleanup operations, recovery behavior, and assumptions hidden behind successful synchronization cycles. Most organizations never test those scenarios, because day-to-day operations rarely require them. A merger, a divestiture, a large workforce transition, a compliance deadline: those are the wrong moments to discover an undocumented default.
Two practices made the difference in this engagement. First, treat the provisioning log as the authoritative record of what the engine actually did. Configuration screens show intent; logs show execution. Second, design scope filters so every worker has an explicit, tested outcome rather than depending on undocumented edge-case behavior.
How RBA Approaches Identity Provisioning
This engagement reflects how we approach identity provisioning at RBA. Getting the hire, change, and termination scenarios working is only the beginning. Our validation process includes scope entry and exit, null-value handling, retry and recovery behavior, volume safeguards, and the non-default settings that can change how the provisioning engine behaves under exceptional conditions. Every conclusion is validated against provisioning log evidence, not configuration screens, and documented so the reasoning survives long after the implementation is complete.
If your organization provisions identities from Workday into Active Directory, Entra ID, or both, and you’ve never tested what happens at the edges, it’s worth doing before a business event forces the question. Let’s talk.
About the Author
Cody Billings
Senior Principal Consultant & Partner, RBA | CISSP
With more than 25 years in IT across both client and consulting roles, Cody helps organizations secure cloud platforms and modernize identity. His work spans Zero Trust and SASE, Microsoft Purview data governance, identity lifecycle modernization with Microsoft Entra ID Governance and Workday-driven provisioning, and AI governance and Copilot readiness.
He has found that the hardest part is rarely the technology itself. It’s connecting security decisions to business outcomes and turning those decisions into action.