A staff register that drives Microsoft 365 account changes

The work

I built this process for a community organisation to connect staff information with the account and access changes needed in Microsoft 365. The organisation is not named, and no client data or internal screenshots are published here.

The build uses a SharePoint list as the staff register, Power Automate to respond to changes, and a PowerShell module to carry out the account work. The module is kept under version control.

How the process runs

1. 1. A staff record starts the process

   A SharePoint list holds staff details, roles, start dates and end dates. Power Automate triggers when a record is added or changed, and the start date determines when the person should receive access.

2. 2. The account receives the access for the role

   A PowerShell module provisions the user and assigns role-based groups. Group membership drives Microsoft 365 licensing and access to Teams and SharePoint. Mailbox access is delegated directly where required.

3. 3. A change updates the existing account

   Role changes, name changes and other user details update through the same process. A person can hold more than one role. When a role ends, its access is removed rather than simply adding the new role on top.

4. 4. An end date starts offboarding

   End-date processing disables the user and removes access through a formal offboarding process. A scheduled run also processes end dates, so the process does not depend solely on a record being edited at the right moment.

The details that matter

A person may need more than one role. The process supports that, rather than treating every role change as a complete replacement. Where a transition needs a grace period at the start or end, that can be included in the agreed scope.

For an urgent departure, the process takes all reasonable steps to end current sessions. That wording matters: disabling an account and requesting session revocation is not a promise that every application session ends immediately.

Group-based licensing and application access also need to be designed together. The right group membership is useful only if the necessary licences and permissions exist in the tenant.

What this example demonstrates

The implemented process connects staff records to account creation, access changes and offboarding. It gives those changes a common starting point and a scheduled way to process end dates.

No time saving or financial return was measured for this case study. It describes the implementation, rather than putting a number on an outcome that was not recorded.

Planning a similar process

Your source of staff information might be an HR system rather than SharePoint. Before building, we would agree who maintains that information, the role-to-access mapping, handling of exceptions and the controls needed for your organisation.

For your project, we would also agree approval steps, how failures are reported and retried, and how data is retained. The scope identifies the licences and application access required.