provisioning deprovisioning conflict: rehired employee account disabled error fix

TL;DR

Reactivate the original identity and stop the deprovisioning source from re-disabling it. Confirm the HR rehire record reuses the original worker identity, cancel or supersede the lingering termination in every feed that writes account status, reactivate the directory and app accounts in dependency order, and verify the hire signs in while the next sync leaves the account enabled.

provisioning deprovisioning conflict: rehired employee account disabled

Use this when

• A rehired employee account keeps returning to disabled after being manually enabled.
• HR shows an active rehire while one feed still carries the old termination.
• The identity platform log shows disable actions arriving after enable actions.

Not for this skill when

• The rehire was processed as a brand-new worker with a new identity. Use the duplicate identity workflow.
• The account is disabled by a security hold. Clear the hold through security first.

Steps

1. Open the identity platform lifecycle log and the HR worker history for the affected hire and capture the full error detail, the operation that failed, and the identifiers involved, rather than working from the summary banner alone. Keep one hire as the test case for every change so cause and effect stay clear. Verify: the full error detail and one test hire are recorded
2. List every status write for the person across the HR feed, directory sync, and app provisioning for the last cycle, in timestamp order, to find which source still sends the terminated state and overwrites the reactivation. Verify: the conflicting source write is identified with its timestamp
3. Correct the source of the stale state: link the rehire to the original worker record in HR so the feed sends one active identity, or exclude the superseded termination record the integration still reads, confirming with HR which record is authoritative. Verify: the feed preview for the person shows a single active state
4. Apply the correction in the identity platform and save it, then re-run provisioning for the single test hire only and read the fresh log entry end to end. If it still fails, treat the new detail as the current cause and do not stack further changes on top. Verify: the test hire provisions successfully or a new specific detail replaces the old one
5. Reactivate in dependency order once the feed is clean: directory account first, then the identity platform profile, then downstream apps, confirming each layer stays enabled after its own sync rather than enabling everything at once. Verify: the hire downstream checks pass in their own systems
6. Watch the next full sync cycle and confirm no disable write lands, then document the rehire linking rule for HR operations so future rehires reuse the original worker record from the start. Verify: a full cycle completes with the account still enabled

Why it happens

Provisioning and deprovisioning are both automated writers of the same account state, driven by HR status. A rehire processed on a duplicate or lingering record leaves one writer sending active and another sending terminated, and the last write wins each cycle, which looks like an account that will not stay enabled. The conflict is a source-data identity problem, not an account problem, so manual enables always lose. Making HR carry one authoritative active record removes the opposing write and lets normal lifecycle automation hold the correct state.

Variants and edge cases

Apps re-enable but the directory does not

The directory is usually mastered by the HR feed directly. Fix the feed state there before touching app-level reactivations.

Rehire after a long gap with a purged account

If the original account was fully deleted under retention policy, create fresh and document that history could not be restored, rather than fighting a half-purged state.

Contractor to employee conversion variant

Conversions carry the same conflict when the contractor record terminates as the employee record activates. Sequence the two records so activation lands last.

Compatibility: Applies to HR-driven lifecycle provisioning in Okta, Entra ID, and connected apps. Requires HR system and identity admin coordination.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst9zKID3C587imaYhZKjH8g

Resolved from the public thread: https://vectle.com/posts/pst9zKID3C587imaYhZKjH8g

Thread query: provisioning deprovisioning conflict: rehired employee account disabled error fix

TL;DR: Reactivate the original identity and stop the deprovisioning source from re-disabling it. Confirm the HR rehire record reuses the original worker identity, cancel or supersede the lingering termination in every feed that writes account status, reactivate the directory and app accounts in dependency order, and verify the hire signs in while the next sync leaves the account enabled.