why do deprovisioned users still consume licenses after offboarding failed

Not specified by the original author.

TL;DR

The license lives in the app, not the IdP. Offboarding that only deactivates the IdP account leaves app licenses assigned. Add explicit per-app license-removal steps to the offboarding workflow and clean up the current zombies manually.

why do deprovisioned users still consume licenses after offboarding failed

Use this when

• License counts stay high after users are offboarded.
• The IdP shows the user deprovisioned but apps still list them as licensed.
• Finance questions the SaaS bill after a round of departures.

Not for this skill when

• The IdP account itself is still active. Fix the deprovision first.
• Licenses are consumed by active users. That is a purchasing question.
• A single app holds the license. Fix that app directly.

Steps

1. List the apps where the departed user still holds a license. Verify: you have the full list, not just the obvious apps.
2. For current zombies, remove the licenses manually per app. Verify: each app's license count drops.
3. Add license-removal steps to the offboarding workflow for every app on the list. Verify: the workflow covers all of them.
4. Re-run offboarding for the affected users through the fixed workflow. Verify: it completes.
5. Verify license counts drop and stay down after the next offboarding. Verify: the fix holds.

Variant phrasings

licenses not freed after offboarding

The symptom-first phrasing.

zombie licenses

The short search.

deprovisioned user still licensed

The state-first phrasing.

Compatibility: Any IdP plus SaaS app combination. The pattern is universal.

Why it happens

IdP deprovisioning and app license assignment are loosely coupled. Most offboarding workflows were built to disable the identity and never learned to release the licenses, so seats leak with every departure.

Edge cases / pitfalls

• Apps where deprovisioning should free the license but the connector is broken; fix the connector, not just the workflow.
• Licenses held via group membership that re-adds them after manual removal; fix the group.
• The 30-day soft-delete window in some apps holding the license; account for the delay.
• Shared and service accounts that look like zombies but are still needed.

Provenance

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

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

Thread query: why do deprovisioned users still consume licenses after offboarding failed

TL;DR: The license lives in the app, not the IdP. Offboarding that only deactivates the IdP account leaves app licenses assigned. Add explicit per-app license-removal steps to the offboarding workflow and clean up the current zombies manually.

Not specified by the original author.

TL;DR

Group-based licensing re-adds the license as long as the account stays in the licensed group, or the deprovision never removed the direct assignment. Remove the group membership or the direct license; disabling the account alone is not enough.

why do inactive accounts keep their M365 licenses after deprovision failed

Use this when

• Inactive or deprovisioned accounts still show M365 licenses.
• Removing the license manually works, but it comes back.
• Offboarding disables the account but licenses persist.

Not for this skill when

• The account is still active in the IdP. Fix the deprovision first.
• The license is needed for data retention. Use a deliberate retention license instead.
• No license is actually consumed. Verify in the admin center before acting.

Steps

1. Check whether the license comes from a group or a direct assignment. Verify: you know the source.
2. Remove the user from the licensing group, or remove the direct license. Verify: the source is gone.
3. Confirm the license drops from the account. Verify: the admin center agrees.
4. Fix the offboarding workflow to include this step. Verify: the workflow covers it.
5. Verify on the next termination that the license releases. Verify: the fix holds.

Variant phrasings

M365 license not removed

The symptom-first phrasing.

group licensing re-adds

The cause-first search.

inactive keeps license

The state-first phrasing.

Compatibility: Microsoft 365 license management with Entra ID group-based licensing.

Why it happens

Group licensing is declarative: membership equals license, regardless of account state. Disabling the account does not remove the membership, so the license persists by design.

Edge cases / pitfalls

• Dynamic groups re-adding the user automatically; fix the rule, not just the membership.
• The 30-day soft-delete window holding the license on deleted accounts; account for the delay.
• Direct assignments surviving alongside group cleanup; check both sources.
• Retention needs: a shared mailbox or archived state may be the right answer, not just license removal.

Provenance

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

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

Thread query: why do inactive accounts keep their M365 licenses after deprovision failed

TL;DR: Group-based licensing re-adds the license as long as the account stays in the licensed group, or the deprovision never removed the direct assignment. Remove the group membership or the direct license; disabling the account alone is not enough.

Not specified by the original author.

TL;DR

Work the backlog directly: export HR terminations and IdP actives, diff them, bulk-deprovision the zombies, remove their app licenses, then fix the offboarding workflow trigger so the backlog stops growing.

failed to deprovision zombie accounts consuming paid seats after offboarding

Use this when

• Terminated employees still show active in the IdP.
• Paid seat counts stay high after departures.
• Offboarding is believed to work but the numbers say otherwise.

Not for this skill when

• The users are actually active. That is a license optimization question.
• The IdP is correct but apps hold licenses. That is per-app cleanup.
• There is no HR feed to diff against. Build the source of truth first.

Steps

1. Export HR terminations and IdP actives for the same period. Verify: both lists are complete.
2. Diff them to find terminated-but-active accounts. Verify: each one is genuinely terminated.
3. Bulk-deprovision the zombies. Verify: their IdP status changes.
4. Remove their app licenses. Verify: seat counts drop.
5. Fix the offboarding workflow trigger, the HR feed or the scheduled job that missed them. Verify: the next cycle's diff is empty.

Variant phrasings

zombie accounts licenses

The short search.

offboarding backlog

The cause-first phrasing.

terminated users active

The state-first search.

Compatibility: Any HR system plus IdP combination.

Why it happens

The offboarding trigger broke silently, through a dead HR feed, a disabled scheduled job, or a changed field name. The backlog is the symptom; the trigger is the disease.

Edge cases / pitfalls

• Contractors not in the HR feed; they need their own trigger.
• Shared accounts that look like zombies but are still needed; verify before deprovisioning.
• The HR feed using a different identifier than the IdP; normalize before diffing.
• Rehires appearing as terminated in a stale HR export; check dates.

Provenance

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

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

Thread query: failed to deprovision zombie accounts consuming paid seats after offboarding

TL;DR: Work the backlog directly: export HR terminations and IdP actives, diff them, bulk-deprovision the zombies, remove their app licenses, then fix the offboarding workflow trigger so the backlog stops growing.