License Assigned, App Still Missing
Provisioning a new hire looks finished the moment the checklist says it is. License assigned. Mailbox created. Account shows active. On paper, done.
Then the ticket comes in three days later. Teams will not open. A shared drive is not showing up. A group-based app never picked up the new license. Nothing about the account is broken. It is just that "provisioned" and "fully functional" are not the same milestone, and most onboarding checklists only check for the first one.
Why the Gap Exists
License assignment kicks off a background process, not an instant state change. When a Microsoft 365 license is assigned to a user, the services behind that license do not all activate at the same time. Exchange Online provisions the mailbox. SharePoint provisions OneDrive storage. Teams provisions the user's presence. Each service has its own provisioning timeline, and none of them guarantee instant availability.
Group-based licensing adds another layer. If a user's license is assigned through group membership rather than directly, the license is not applied until the group membership syncs and the licensing engine processes the change. That engine runs on its own schedule. If the group membership was assigned through Entra Connect from on-prem AD, the sync lag from the connector adds to the wait.
Every one of these steps has its own timing, and none of them surface as a failure in the admin console. They surface as a ticket from a confused new hire on day three who assumes IT forgot something.
What This Looks Like from the Help Desk
The tickets that come in from this gap follow a predictable pattern. The new hire was told they would be set up by their start date. They log in and email works. They try to open Teams or access a shared drive, and it is not there. They contact IT. The agent checks the admin console, sees the license is assigned, sees the account is active, and cannot reproduce the problem.
The issue is not that something failed. The issue is that the provisioning is still in progress, and no one told the new hire (or the help desk) that "license assigned" is an intermediate state, not a final one.
"Account created" is a real milestone. It is just an earlier one than most checklists treat it as.
This creates a frustrating experience for everyone involved. The new hire feels forgotten. The help desk agent cannot find anything wrong. The onboarding team thinks they finished. The ticket sits open while everyone waits for a background process that nobody is tracking.
Building the Delay Into the Process
The fix is not faster provisioning. Microsoft controls the provisioning timelines for its services, and most of them complete within minutes to a few hours. The fix is acknowledging that the onboarding process has a built-in delay and planning around it.
Set expectations with the new hire. A simple note in the onboarding communication that says "some applications may take up to 24 hours to appear after your account is activated" prevents most of these tickets. The new hire knows to wait before calling.
Add a verification step after the delay window. Instead of closing the onboarding ticket when the license is assigned, build in a follow-up check 24 hours later that confirms all expected services are active. This catches the cases where something genuinely did not provision rather than letting the new hire discover it.
Document which services lag. In most M365 environments, Exchange provisions fastest, OneDrive takes longer, and group-based app assignments take longest. Knowing that order helps the help desk agent triage the "my app is missing" ticket without escalating unnecessarily.
Separate "provisioned" from "ready." The onboarding checklist should have two milestones, not one. The first milestone is that all licenses and group memberships are assigned. The second milestone is that all expected services are confirmed active. The gap between those two milestones is the provisioning window that most checklists skip.
Why It Keeps Happening
This pattern persists because the admin console does not distinguish between "license assigned" and "service fully provisioned." The license shows as assigned. The account shows as active. Everything in the admin view looks correct. The only signal that provisioning is incomplete comes from the end user, who reports that something is missing.
Until admin tooling surfaces provisioning status at the service level rather than the license level, this gap will continue to generate tickets. The most practical response is to build the delay into the process and stop treating license assignment as the finish line.