A new-hire ticket becomes a provisioned Microsoft 365 account. A leaver ticket becomes a safely de-provisioned one. Both run unattended when it's safe, and stop when it isn't.
Coverage
Onboarding and offboarding are the two highest-volume, highest-risk Microsoft 365 tickets an MSP handles. Both are repetitive enough to automate and consequential enough that a mistake reaches the client the same day. DaemonLayer runs both from a single PSA ticket — no forms, no templates, no special formatting from the person who asked.
DaemonLayer pulls the name, start date, title, department and manager from the ticket. It builds the account on the client's own naming convention, checks for duplicates, infers group membership from the existing directory, and assigns a licence. The temporary password is emailed to the requester — never written into the ticket.
A leaver ticket triggers a live protected-account check, then a fixed de-provisioning sequence: disable, revoke sessions, convert the mailbox to shared, remove licences and groups, and strip delegate access across the tenant. The account is soft-deleted and restorable. Nothing is hard-deleted, ever.
User Onboarding
Everything below happens from one ticket, with no technician touching a console.
The new hire's name, start date, job title, department and manager are extracted from plain English. Anything genuinely missing triggers one targeted clarification question back to the requester, not a guess.
DaemonLayer detects how the client names users — firstname.lastname, flastname, whatever they already use — and builds the UPN to match, folding diacritics on the way (Renée Böhm becomes renee.bohm@). Duplicates are caught before anything is created, not after.
Group access is resolved from the client's existing Microsoft 365 directory through a four-tier cascade, explained below. The model reads the ticket. It does not decide who gets access to what.
Role-assignable groups are removed from the resolved set before the account is created. This gate runs in code on every onboarding, whichever tier produced the group list.
The client's default Microsoft 365 licence is assigned if a seat is free, and a matching contact is created in the PSA. If seats are exhausted, the account is still created and the gap is flagged — a licence problem doesn't abort the onboarding.
The temporary password is emailed directly to the requester, and the new hire must change it at first sign-in. The ticket gets a public confirmation and an internal audit note listing the groups assigned, the evidence used, and anything skipped.
How It Works
Nobody writes "add her to SG-Finance-RW" in a new-hire ticket. Group access has to be inferred from the directory the client already has. DaemonLayer does that in four deterministic tiers, and stops at the first one that produces a confident answer.
If every user at the client already shares the same set of groups, the new hire gets that set. The simplest case, and the most common one at small clients.
Where the directory isn't homogeneous, the new hire is matched against existing users with the same job title or department, and membership is inferred from what that peer group actually has.
If peers disagree, DaemonLayer looks at how recent hires in similar roles were actually provisioned and converges on that pattern — the most current signal of what the client does today.
No confident answer means no automated answer. The ticket is suspended and a technician assigns groups manually. DaemonLayer does not guess at access.
Before any account is created, every role-assignable group is removed from the resolved set. This is deterministic code that runs on every onboarding, regardless of which cascade tier produced the group list. It is not a setting you can misconfigure, and approving the request does not bypass it. You are liable for your clients' Microsoft 365 tenants — a safety gate that a tired technician can click through isn't a safety gate.
User Offboarding
Offboarding is where MSPs get hurt: sessions left alive, delegate access nobody remembered, a mailbox deleted before anyone read it. DaemonLayer runs the same sequence every time, and never permanently deletes anything.
The account is disabled and every active sign-in session is revoked. A disabled account with a live token is still a live account.
Mailbox size is read via Exchange Online, then the mailbox is converted to a shared mailbox so the team keeps access to its contents.
Under 50 GB, the licence is removed and the seat goes back to the client. At 50 GB or above it is retained, because Microsoft requires a licence on large shared mailboxes. The rule is applied automatically — no technician has to remember it.
Remaining Microsoft 365 licences and all non-dynamic group memberships are removed.
The account moves to Deleted Users and can be restored for 30 days. If the leaver comes back, or somebody offboarded the wrong Tom, it's recoverable.
The step everyone forgets. Every other mailbox in the tenant is scanned for access the leaver held — Full Access, Send As, Send on Behalf, Calendar — and it is all removed.
The requested email handover runs — forward, grant access, or both — always internal, because external forwarding is never automated. Aliases are released or held per client configuration, the PSA contact is deactivated, and the ticket receives an internal checklist of every action taken or skipped, with reasons.
Built-In Guardrails
A live check runs against Microsoft 365 the moment the ticket lands. Any account holding a privileged directory role — Global Admin, User Admin, Helpdesk Admin or similar — goes straight to the service desk. It never reaches an approval card, so nobody can click it through. The same check runs again immediately before changes are applied, which means a role granted after the ticket was opened still gets caught. Cached data cannot bypass it.
A per-client daily velocity limit contains the damage a single bad ticket can do. A five-person layoff processed at once trips the limit and routes the overflow to the service desk — and because the limit is per client, no other client's automation is touched.
Authorization
Onboarding and offboarding both sit at the highest risk tier, so the sender has to clear a confidence score of 90 before anything runs unattended. DaemonLayer checks, in order: is the sender the target user's manager in Microsoft 365? Is the sender a known approver scoring above the threshold? If neither holds, the workflow suspends and a technician gets an approval card itemising exactly what will happen. Approver scores are built from Microsoft 365 and PSA signals, and they rise each time a technician approves the same person — so the requests that need a human get fewer over time.
Time Saved
Onboarding and offboarding are fixed-rate billable work that a technician currently does by hand, in a console, at eleven o'clock at night before a Monday start date. DaemonLayer runs both unattended when it's safe, escalates when it isn't, and posts an audit note either way.
FAQ
Yes. DaemonLayer reads a plain-English new-hire ticket in your PSA, extracts the name, start date, job title, department and manager, then creates the Microsoft 365 (Entra ID) account, assigns groups and a licence, and creates the matching PSA contact. No form, no template, no special formatting from the requester.
Through a four-tier deterministic cascade: a homogeneous directory match, then title and department peer matching, then recent-hire convergence, then escalation to a technician. The language model only extracts what the ticket says. It never decides access. If no tier produces a confident answer, the ticket goes to a technician.
A hard gate in code. Every role-assignable (privileged) group is stripped from the resolved set before the account is created, no matter which cascade tier produced it. It is not a setting, and a technician approving the request does not bypass it.
No. Nothing is ever permanently deleted. The account is disabled, sessions are revoked, the mailbox is converted to a shared mailbox, and the account is soft-deleted — restorable from Deleted Users for 30 days.
The offboarding never runs. A live check against Microsoft 365 at ticket time routes any account holding a privileged directory role — Global Admin, User Admin, Helpdesk Admin and similar — straight to the service desk. It never reaches an approval card. The same check runs again immediately before any change is applied.
Onboarding and offboarding are triggered from tickets in your connected PSA and write results back to it. DaemonLayer integrates with ConnectWise Manage, Autotask, HaloPSA and Jira, including PSA contact creation on onboarding and contact deactivation on offboarding.
Related
Connect your PSA, and DaemonLayer starts triaging, resolving, and routing, no scripting, no setup calls. Cancel anytime.
Prefer a walkthrough? Book a demo →
