The directory only answers whether someone may sign in
Your directory answers one question about a person, which is whether they may sign in. Every business application answers a different one, which is what that person may do once inside, and each answers it in a vocabulary of its own. Dataverse has security roles and business units. Salesforce has profiles and permission sets. Workday has security groups hung off positions and supervisory organisations. None of those translate cleanly into each other.
Creating the account is the easy half of the lifecycle. Entitlement lives inside each application's own model, and those models disagree about what a person even is. Workday holds a worker occupying a position. Salesforce holds a user with one profile and a pile of permission sets. Dataverse holds a system user in a business unit whose team memberships carry roles of their own. One transfer means something different in each.
Three events change what those models should say. Someone joins, someone moves, someone leaves. The three are not equally solved in most estates, and the gap between them is predictable enough to design around.
Joining is solved because joining fails loudly
Joining works in most organisations for one reason, which is that failure shows up within hours. A new starter sits through an induction with no access, the manager escalates before lunch, and the service desk holds a ticket with a name, a start date and somebody waiting at the other end of it. Nobody has to go looking for the problem.
What matters for the rest of the lifecycle is the shape of those first grants. If the join hands out a named bundle tied to a job family, the mover and leaver steps have something specific to take away later. If it hands out forty individual permissions assembled by whoever was on shift, nothing downstream can unpick what was granted or why. Record the reason for each grant against the position rather than the person.
A transfer adds access and almost never takes any away
Moving is where organisations actually fail, and they fail quietly. A finance analyst moves into procurement, and the queue receives a request for procurement access. No request arrives to remove the finance access, because removing it inconveniences nobody. During the handover weeks it even looks useful that she can still close her old month end.
Repeat that across three moves in five years and you get an entitlement set no approver would have signed off in one sitting. The long-tenured employee who has passed through finance, procurement and shared services can raise a purchase order, approve it and watch the payment run. Nobody granted that combination. It assembled itself one transfer at a time, which is the problem underneath segregation of duties when one person wears four hats.
The same accumulation shows up in the security model itself. Someone needs new access, the quickest path is a new group, and the tenant ends up carrying hundreds of groups nobody can tell apart, which is Workday security group sprawl.
Fix the mover case before the other two, precisely because it is the silent one. A broken joiner produces a phone call within a day. A broken leaver produces an audit finding within a year. A broken mover produces nothing at all. Make the transfer one change that removes the old position's entitlements and grants the new ones together. Where a handover genuinely needs the old access, grant it back with an expiry date somebody has to defend.
Disabling the sign-in leaves most of the leaver behind
Disabling the directory account is necessary and it finishes very little. It stops interactive sign-in, which stops the person. It does nothing about the integration user they built during a project, the API token issued in their name, the delegated approval that still routes through them, the scheduled job running under their credentials or the shared mailbox they own.
Integration accounts are the worst of those, because they outlive the interruption you are trying to cause and usually carry wider rights than the human did. They need a register and an owner of their own, which is the argument in service account identity across platforms. Scheduled automation fails more gently. A flow that has run nightly for two years stops when its owner's account goes, and the business finds out by missing a report, which is flow ownership debt arriving late.
Change the leaver question to get a useful answer. Rather than asking what this person can sign in to, ask each application what still runs under their identity. Those are two different lists, and the second one breaks things in the weeks after they go.
Records that still point at somebody who left
Records owned by a departed person are an architectural problem well before they are a tidiness problem. Ownership carries behaviour in most business applications. It decides routing, it decides what rolls up in reporting, and on several platforms it decides who else can see the row at all.
Salesforce sharing through the role hierarchy follows the record owner upward, so an inactive owner leaves rows reachable through a branch nobody manages. In Dataverse the owning user and business unit drive inheritance, so an orphaned owner quietly drops rows out of views whole teams depend on. Assignment rules naming an individual stop firing, and pipeline reports grouped by owner keep a column for somebody who left in March.
Decide reassignment before your first leaver, object by object, with a named fallback owner and a rule for work in flight. Approvals already given, audit history and the author of a posted journal stay attributed to the person who acted, because rewriting them destroys the record of who did what.
Let the worker record start the clock
HR knows about a leaver before IT does, usually by days and sometimes by weeks. The resignation conversation ends with a change in the HR system, and only later does somebody remember to raise a ticket. That gap is the argument for making the worker record the trigger for the lifecycle, with hires, transfers and terminations published as events the other applications subscribe to.
The join key between those applications has to be a stable immutable identifier, issued once and never reused. Not the email address, which changes with a marriage or an acquisition. Not the name, for the same reason and worse. A business application will not refuse a changed identifier, it will create a second person and carry on, and you find the duplicate months later. The same reasoning runs through a field guide to durable business keys.
Effective dates and revocation dates are different things and should be allowed to differ. A termination effective at month end does not mean access should survive until month end. Run two clocks. One follows the HR effective date for entitlement tied to the position. The other fires on notice for anything sensitive, such as data exports, payment runs and administrative rights. Revoke on the earlier of the two unless a named person signs for a dated extension.
Recertification only works if the reviewer can read the list
Recertification is the control everybody buys and few people get value from. It holds up when the reviewer can understand what they are approving. Hand a manager forty rows reading FIN BU Contrib 03 and SysAdmin Custom 12, and they will approve all forty inside a minute, and the campaign will report ninety eight percent completion having certified nothing.
The manager is behaving sensibly given an unreadable list, so the fix sits upstream in how you name entitlements. Name a role after what it lets somebody do, in the words that manager would use. Post a journal entry. Approve spend above fifty thousand. A reviewer can answer whether someone needs that. Nobody can answer whether they still need Role 2. Reading an entitlement set before certification is the method in the Salesforce permission audit guide.
The check to run this week takes an afternoon. Pick three people with long tenure across several departments, pull their entitlements from your two largest business applications, and lay both lists side by side on one page. Take it to their current managers and ask one question per line, which is whether the person used that access this quarter. The silence you get on half the lines is the size of your mover problem.
