Onboarding and Offboarding Across a Franchise Network

A new staff member should arrive to find their accounts already created, their role-based access assigned, their device enrolled and their line-of-business applications ready — so they are productive from the first shift rather than waiting for IT to catch up. The joiner process should be triggered before the person starts, not after they walk through the door. Anything that has to be requested on the day is a gap in the process, not a feature of it.

Copying a colleague's access gives a new starter everything that person accumulated over years — including permissions they no longer need, tools they never used and access to areas unrelated to their role. That is how permission creep begins, and it is why every offboarding becomes harder than the last. Role-based access replaces the copy approach by assigning a defined set of permissions for the role, not the person sitting in it.

Access removal should be tied to the departure itself, not to a later review or a convenient pause in the schedule — ideally before the person's final shift ends, and certainly before any account remains active overnight after a departure. The trigger should be the leaver notification from the location, and the action should be automatic rather than waiting for someone to remember. Any delay is a window in which a former staff member can still reach business systems.

The things most commonly missed are shared store accounts nobody personally owns, personal devices that go home, mobile and remote access tokens, third-party supplier logins, and accounts at sites head office does not manage directly. Each of these survives offboarding because nobody is specifically responsible for it. A complete leaver process names every category and assigns an owner to each.

Head office owns the identity and access layer — the Microsoft 365 tenant, the conditional access policies and the central directory — even at franchisee-owned sites, because a gap at one location is a network risk. The franchisee owns the local notification: telling head office someone has left, returning devices and confirming local systems are closed out. The split has to be documented so neither side assumes the other handled it.

Shared store accounts should be replaced with individual accounts wherever possible, because an account nobody owns is an account nobody removes — and it becomes a permanent back door into the network. Where a shared account is genuinely unavoidable, it should have a named owner at the location, a strong password that is rotated on a schedule and multi-factor authentication tied to a device rather than a person. It should appear on the access review list so it is never forgotten.

The device should be enrolled in a management platform that allows head office to remotely wipe it the moment the person leaves, removing business data and access without waiting for the device to be returned. If the device is personally owned, the management profile should separate business data from personal data so the business side can be removed without touching the personal side. A device that goes home with someone who has left is one of the most common gaps in franchise offboarding.

Third-party and supplier access should be inventoried as part of the joiner process, so that when someone leaves there is a list of external systems to close out — not a scramble to remember what the person could reach. Where a third-party system supports single sign-on through Microsoft 365, removing the Microsoft account removes the third-party access automatically. Where it does not, the leaver process needs a named step for each external system.

Role-based access means permissions are attached to a defined role — store manager, floor staff, area manager — rather than to an individual, so that onboarding becomes assigning a role and offboarding becomes removing it. When someone changes role, their old role is removed and the new one assigned, rather than layering new permissions on top of old ones. It is the single change that makes both joiner and leaver processes repeatable across a network.

Yes, if the identity layer is centralised in Microsoft 365 — head office can disable an account, revoke conditional access and trigger a device wipe regardless of which site the person worked at, because the account lives in the tenant head office owns. That is the structural reason for centralising identity rather than leaving each site to run its own directory. The local site does not need to act for the access to be removed.

Onboarding a new location means provisioning the tenant configuration, licences, security policies, device profiles and role templates before the site opens, so that every staff member who joins afterward is assigned a role that already exists rather than having access built from scratch. The location onboarding is the blueprint; the staff onboarding is the process that runs on top of it. Both should be repeatable rather than invented per site.

You run an access review — a structured check of who holds which role, which accounts are active and which devices are enrolled — and you do it on a schedule rather than only when something goes wrong. Centralised identity in Microsoft 365 makes this a report rather than a site-by-site audit. If the answer takes longer than a report, the access is not centralised enough to be managed.

A role change should trigger the same removal-and-assignment process as a departure followed by an arrival — the old role's access is removed and the new role's access is assigned, rather than adding the new permissions on top of the old ones. Without this, people accumulate access across every role they have ever held, and the access review becomes impossible. The joiner-leaver process should treat role changes as a first-class event, not an afterthought.

The processes decay when nobody owns them, so each one needs a named owner inside head office and a review point on a schedule — not a one-off document that sits in a folder. The access review is the mechanism that catches the decay: if the review finds accounts that should have been removed, the process has a gap, and the gap gets fixed. A process that is never reviewed is a process that has already stopped working.

Start with identity: centralise accounts in Microsoft 365 if they are not already, so that every person and every site is visible in one tenant rather than scattered across local directories. Then define the roles the network uses and the access each role needs, because role-based access is the foundation both processes are built on. Documenting the process comes after the identity layer is in place — a document describing a system that does not exist yet is just paper.