⏰ Support Available: Mon-Fri 4:00pm-6:00am | Weekends 24/7
Microsoft Entra identity management
People get the right account and access on the day they start. Their access changes when their role does. A departure follows a controlled process. All of it runs from one staff record, not from whoever remembers to send an email.
The usual name for this is joiner, mover and leaver: somebody joins, somebody changes role, somebody leaves. I design the process and build the automation behind it in Microsoft Entra ID, which Microsoft used to call Azure Active Directory, or Azure AD.
From favours to rules
In most organisations each of these moments is a favour. A manager emails somebody, a new account is copied from a colleague's, and access is added whenever it is asked for. Nothing is ever taken away, because nobody is ever asked to take it away.
Identity and access management replaces the favours with rules. A staff record says who somebody is and what role they hold, and automation makes Microsoft 365 match it. That is useful to a business owner who wants employee onboarding and offboarding to be reliable, to a community organisation with employees, volunteers and contractors coming and going, and to IT and HR teams who want the two sides to agree.
Joiners: ready on the first day
A new starter's record is the trigger. The account is created from it, and everything the role needs follows from the role. This is Microsoft 365 user provisioning done once, by rule, in place of a request for each thing.
Account provisioning
A Microsoft 365 user account is created from the staff record, with the name, role and details taken from the record and not typed again by hand.
Role-based groups
The person is added to the groups for their role. These are ordinary access groups that decide what a role can use. They are not Entra administrator roles, which are a separate thing and held far more tightly.
Licences
Group-based licensing assigns the Microsoft 365 licence that role needs, so nobody starts without one and nobody is given a plan they will not use. Where your plan does not allow it, the automation can assign licences directly and keep them reconciled.
Teams and SharePoint
The same groups open the teams and sites the role works in, so access follows the job and not a list of requests.
Mailbox delegation
Access to the shared mailboxes a role looks after is applied in the same step, to the mailboxes that role is meant to have.
Start dates
A record entered three weeks early does not mean access three weeks early. Where you want it, a grace period can be added at the start or the end of somebody's time.
Movers: access that changes with the role
This is the stage most processes do not have at all. Somebody moves from one team to another, the new access is added because they ask for it, and the old access stays because nobody asks for it to go. Repeat that for a few years and long-serving staff can reach more than anybody ever decided they should.
Role and department changes
The role is changed on the staff record. The person moves into the groups for the new role and out of the groups for the old one.
Removing as well as adding
What the old role needed is taken away at the same time as the new access is given. That is the half that stops permissions piling up as people move.
Names and other details
A change of name or a corrected detail is made once, on the record, and carried through to the account.
More than one role, and handovers
A person can hold more than one role at once. Where a handover needs it, access from the old role continues for an agreed grace period and then comes off, so an exception always has an end date.
The same idea applied to shared mailboxes, where access lapses unless somebody renews it, is in what managing thousands of shared mailboxes taught me about governance.
Leavers: a controlled departure
A departure is the stage with consequences in both directions. Too slow, and a former staff member still has access. Too hasty, and a mailbox or a set of files the organisation needed has gone.
Recorded end dates
An end date on the staff record is the trigger. It can go on the day somebody resigns, or on the day a contractor starts.
Scheduled departures
A scheduled process checks those dates and begins the departure steps when one arrives, without anybody needing to remember.
An urgent departure process
A short, separate process for the day somebody leaves without notice, which a named person can start straight away.
Disabling the account, removing access, dealing with sessions that are already signed in, preserving the mailbox, applying retention and removing the licence have to happen in an agreed sequence. Some of those steps defeat others when they are done in the wrong order, and some take time to reach every service.
So the sequence is designed with you and written down. I do not promise that every connected system loses access at the same instant, because that is not how these services behave.
The mechanics of a single departure, and why the order matters, are on the employee offboarding page. The urgent case is covered in the first 24 hours after somebody leaves unexpectedly.
Two ways to build it
There are two sound ways to do this. Which one fits depends on your systems, your licensing, what you need it to do, and who will look after it afterwards.
A staff register with Power Automate and PowerShell
A SharePoint list is the staff register. Power Automate starts the work when a record is added or changed, and a PowerShell module carries it out.
It suits an organisation with no HR system that can feed Microsoft Entra, or with rules particular enough that they need writing down as code. It is custom automation, so somebody has to own it and keep it maintained.
HR integration with Microsoft Entra provisioning
Where a supported HR system holds the staff record, Microsoft Entra can provision accounts from it, through a prebuilt HR connector or API-driven inbound provisioning. The HR system becomes the authoritative source and there is less custom code to look after.
It depends on a supported connector or a usable API, on the HR data being reliable, on your licensing, and on whether accounts live in the cloud or in an on-premises Active Directory. Not every HR system can be connected.
Neither is better in general. Where Microsoft's own provisioning does the job it is usually the right choice, because Microsoft supports it and nobody has to maintain a script. Where it does not fit, custom automation fills the gap, and some designs use both.
Microsoft has a product called Lifecycle Workflows, part of Microsoft Entra ID Governance. Using it needs Microsoft Entra ID Governance or Microsoft Entra Suite licensing, which Entra ID P1 or P2 alone does not include.
Custom joiner, mover and leaver automation built with Power Automate and PowerShell is a different thing and does not use that product. I will tell you plainly which of the two a design relies on, and what it needs you to be licensed for.
A practical example
A community organisation whose staff information, roles and end dates are kept in a SharePoint list. This is what I built for it, using the first of the two approaches. The organisation is not named here, and I am not quoting a saving, because none was measured.
Staff register
A SharePoint list holding each person's details, role and end date.
Workflow and automation
Power Automate starts a PowerShell module when a record is added or changed.
Entra identity
The user account is created or updated in Microsoft Entra ID.
Role-based access
Groups for the role bring the licence, teams and sites. Mailbox delegation is applied directly.
Also on a schedule
End dates on the register are checked on a schedule as well, so a departure is processed when its date arrives and does not wait for somebody to edit the record.
What it does
- When a record is added to the staff register, the user account is created and added to the groups for that person's role.
- Those groups assign the Microsoft 365 licence and give access to the right teams and SharePoint sites.
- Delegation is applied directly to the mailboxes the role needs.
- A start date on the record is respected, so entering somebody early does not give them access early.
- A change of role removes the access that went with the old role and applies the new one. A person can hold more than one role.
- A change of name or an update to somebody's details on the register is carried through to the account.
- End dates are checked on a schedule. When one arrives the account is disabled and its access is removed through a formal offboarding process.
- For an urgent or immediate departure, it takes all reasonable steps to end sessions that are already signed in.
- The PowerShell module that does the work is kept under version control.
How an engagement works
Review what you have
I look at how people are onboarded, moved and offboarded today, and at your identity environment: accounts, groups, licences and anything already automated.
Agree the rules
We settle which staff record is the authoritative one, what each role gets, who is responsible for what, and the exceptions. This step decides whether the rest works.
A programme of work and an estimate
You receive a written programme of work with estimated hours, so you know the size of the job before you commit to it.
Build and pilot
I implement it and pilot it against representative joiner, mover and leaver scenarios before it is applied to everybody.
Document and hand over
You get documentation and a handover, and we agree what ongoing maintenance you want from me, if any.
Implementation is project work, scoped and quoted after discovery. Ongoing maintenance is optional and agreed separately.
An optional place to start
If you want a wider look at the tenant first, the Microsoft 365 Health Check is $599 GST inclusive, fixed. It reviews security, identity, email authentication, sharing and licensing and gives you a written report. It does not include building identity automation, and you do not need one before an identity project.
Who does the work
Hamilton365 is Jamie Hamilton. I have worked in enterprise IT for more than 25 years, including a decade running identity and messaging for an environment of more than 200,000 users. The person who scopes the work is the person who builds it and hands it over.
My Microsoft certifications, including Managing Office 365 Identities and Requirements, are listed with links to their public Credly records on the Microsoft 365 support page. For tenant work beyond identity, see Microsoft 365 consulting.
More detail on each part
This page describes the service. These go into the detail of the individual subjects.
Employee offboarding in Microsoft 365
The order to work in for a single departure, and the steps that are the wrong way round from what you would guess.
What happens to your accounts when staff leave
Why an account outlives the person, what an orphaned account is, and how to find the ones you already have.
The first 24 hours after an unexpected departure
The urgent version, step by step, for the day somebody walks out.
Shared mailbox governance
Access that expires by default, named owners, and what that looks like with twelve mailboxes.
Guest access in Entra ID
Outside collaborators are part of the same question, and they are the accounts nobody is counting.
Microsoft 365 Groups, distribution lists and shared mailboxes
Which kind of group or mailbox to attach a role to in the first place.
Questions about identity management
Discuss identity management
Tell me roughly how it works today and where it goes wrong. I reply personally, usually the same day.
Prefer to talk it through? Call 0403 401 250 or email [email protected]