Key Mistakes in Multi-System User Provisioning
The most common mistakes in multi-system user provisioning are mapping only the happy path, treating approvals as a clean policy tree, assuming SCIM covers every app, forgetting deprovisioning, and automating the request while a technician still makes the change by hand. Each one leaves a person copying data between your PSA, identity provider and vendor consoles.
If you run an MSP, you have probably felt this already. Ticket volume, SaaS sprawl and client expectations all go up, and your techs end up working in five consoles to approve one software request or assign one license. The work looks small, but the cost adds up, so if you're trying to build a profitable MSP, fixing provisioning is one of the most direct ways to win back technician hours.
What multi-system user provisioning covers in an MSP
User provisioning is the work of creating accounts and granting the right access in every system a person needs, then keeping that access correct as their role changes and removing it when they leave. SailPoint describes it as an identity and access management process that uses a person's name, job title, department, entitlements and group memberships to create accounts and grant rights across the IT infrastructure and business applications. OneLogin names the three triggers the joiner/mover/leaver (JML) process.
For an MSP, "multi-system" is the normal case. A new hire at one client might need a Microsoft 365 account and license, group memberships in Entra ID, a seat in a line of business app, a device set up through the RMM and a record in IT Glue or Hudu, while the request and the time entry live in the PSA. Every one of those systems is a place where the process can stall. For the Microsoft side on its own, see Office 365 user provisioning for MSPs.
Why multi-system user provisioning breaks before it delivers value
Most failures have less to do with code than with assumptions. Teams assume that if the tools connect, the workflow is solved. In MSPs, the mess lives in approvals, context, exception handling and the gap between a ticket being understood and a change actually being made.
Mapping the happy path instead of the real workflow
On a whiteboard, a software request looks easy. The user asks for Adobe, a manager approves, a tech assigns the license and the ticket closes.
In reality, the request comes in through email or chat and the user names the wrong product. The approver for this client is different from the approver for the last one. The license lives in a system with a weak API, or no useful API at all. Somebody has to check whether the user already has a seat, whether finance needs to sign off, whether the request is tied to onboarding, whether the PSA ticket has enough context, and whether the user needs instructions after the change.
I've seen this pattern a lot. Teams map the happy path, then the workflow fails on the dozen edge cases that come up every week, and humans clean up the hard parts. That is partial automation, and the technician is still the integration layer.
Counting summaries as finished work
A lot of the market still confuses summarizing with execution. If an AI reads the ticket, rewrites it nicely and suggests the next step, your tech still has to log into the identity provider, check approval, open the admin console, update the PSA and notify the user. The labor is the same, so the only thing that improved is the write-up. That gap is why AI that cannot act on a ticket rarely moves the numbers.
A routine L1 request that takes 10 to 15 minutes, repeated a few hundred times a month, is a margin leak whether the summary was good or not. It wears people down too, because your best techs spend their time on low-judgment work across a stack of tabs, at odd hours, for tickets that never needed that much human attention.
Treating approvals like a neat policy tree
Approvals sound simple until you run them for real clients. One client wants department heads to approve license upgrades and another wants office managers. A third says the finance lead approves anything paid, except existing seats, unless it's a contractor, unless it's urgent, unless the owner already commented in the ticket. Turning that into a clean static tree before go-live rarely works.
This is where a lot of provisioning projects stall. The team realizes they don't have one approval policy; they have history, habits, exceptions and three years of ticket comments. So they delay launch until the model is perfect, and it never is. Your process knowledge is scattered across tickets, chat threads and people's memory, which is why static automation usually fails first on approval-heavy work like software and access requests.
Provisioning mistakes that live between systems
The mistakes above are about process. The next three are about the systems themselves, and they are the ones the identity vendors' own guides spend the most time on.
Assuming SCIM reaches every app
SCIM (System for Cross-domain Identity Management) is the standard most identity providers use to push users into apps. It helps, but it doesn't cover everything. Microsoft's Entra ID documentation lists separate connector paths for SCIM, LDAP, SQL, REST and SOAP web services, flat files through PowerShell, and custom connectors, because apps expose user management in different ways.
Even when an app supports SCIM, coverage can be partial. Atlassian supports SCIM 2.0 to create, link and deactivate accounts from your identity provider, but group sync works for Jira, Confluence and Trello and is not yet available for Bitbucket. So "we have SCIM" can still leave a tech adding someone to a Bitbucket group by hand. For each client, write down which apps provision through SCIM, which through another connector or API, and which still need someone in a vendor console.
Building roles once and never revisiting them
Role-based provisioning is the usual fix for one-off requests, and it works when the roles stay accurate. Delinea's guide points out that role-based provisioning needs careful role definition and ongoing management, and that automated provisioning needs tested rules because a bad rule propagates at speed.
In MSP terms, that's the "set them up like the last person in accounts" request. It copies whatever that person picked up over the years, including access they no longer need. The principle of least privilege, which SecurEnds describes as giving users only the minimum access their tasks require, is much easier to keep when roles are reviewed than when they are cloned.
Treating deprovisioning as an afterthought
Most provisioning work gets built around joiners, so movers and leavers get handled from memory. SailPoint notes that dormant accounts can be gateways to data breaches even when the former user poses no threat. UberEther lists how provisioning failures tend to surface: excess access lingering after role changes, former employees keeping system access, and inconsistent permissions across applications.
The fix starts at the joiner ticket. If every account and license you grant is recorded on the ticket, the leaver ticket can reverse it system by system. Entra ID can also discover existing accounts in connected apps, including local or orphan accounts, which helps when you take over a client whose history you don't have. For the Microsoft 365 side, see offboarding Microsoft 365 users as an MSP, and verify who is asking before you change access, as covered in help desk identity verification.
What bad multi-system provisioning costs an MSP
Getting multi-system provisioning wrong costs hours, margin and client trust at the same time. The time loss is obvious. The harder part is how it compounds across queue health, SLA pressure and technician focus, because every manual handoff creates another wait state.
Small tickets get expensive because the handoffs multiply
A software request sounds tiny: add an Adobe seat, upgrade a Microsoft license, grant shared mailbox access. Small tickets turn expensive when one person gathers context, another finds the approver, someone waits, someone else makes the change, and a fourth person documents it and closes the loop. One MSP told Rallied that new-user onboarding takes "at least 15-20 minutes, maybe closer to half an hour."
Here's the rough math. If an MSP handles 200 to 400 L1 tickets a month and a meaningful share involve cross-system changes, you can lose 50 to 100 hours a month on repetitive, low-judgment work. The U.S. Bureau of Labor Statistics puts the 2025 median pay for computer support specialists at $30.24 an hour, so every one of those hours is paid technician time, before benefits.
Often the ticket involves one actual change. The rest is administrative friction: chasing the approval, logging into the portal, documenting, updating the status and following up. That's coordination work, and you're paying good technicians to do it.
Every extra tool adds another place for the process to fail
MSPs don't operate in one system. The request might start in a chat message, the ticket lives in the PSA, and the identity check happens in Entra ID, Okta, JumpCloud or Google Workspace. Device context sits in the RMM, knowledge sits in IT Glue or Hudu, and the software assignment might happen in a vendor admin console.
So when someone says "we already automated provisioning," ask which part: intake, approval, the change itself, the message back to the user, or the audit trail. Unless the workflow crosses the whole stack, a human is still the integration layer. This is where many MSP owners get burned, because they buy a tool that looks good in one lane and then find the failures happen between systems.
Approval drag you can feel in the queue
Approvals rarely look dramatic on paper, but day to day they create backlog, reopen risk and internal noise. The tech asks for approval, the wrong person gets tagged, nobody responds, another comment gets added, the user asks for an update, and the ticket sits. It finally closes long after the change itself could have been made.
I've watched teams decide that this is just how software requests work. It's a design problem, and it can be fixed. When approvals are fuzzy, delay and access risk both go up.
How to fix multi-system user provisioning
A better approach starts with fewer assumptions, tighter scope and real execution. You don't begin by automating every ticket type. You start with the requests that happen constantly, need little judgment, and already leave a trail in your ticket history.
Start with one repetitive workflow everybody understands
The best starting point is the annoying workflow your team sees every week. Software license requests work well because they touch approval logic, user context, system access and post-change communication in one ticket.
Look at how those requests move today. Where do they come in, who usually approves, which systems get touched, which exceptions come up often, and which actions are safe after approval? It's boring work, and it's the work that decides whether the automation holds up. In my experience, reviewing 100 old tickets tells you more than three strategy calls, because ticket history shows how your MSP actually runs.
Read approval patterns from ticket history
Most teams try to design approval routing from scratch, as if every rule were already documented. Usually it isn't. The patterns exist, but they live in ticket comments, past decisions and client-specific habits.
So mine that history. See who approved what by request type, client, department and scenario, and use it to build a first working version. Where the signal is weak or the request is ambiguous, route it to a human for confirmation. You don't need perfect certainty to get value, and the teams that move fastest are usually the ones willing to let real ticket history define version one.
Design for completion, not isolated steps
A provisioning workflow is only useful if it closes the loop. For software and access requests, that means doing these in sequence:
- Identify the user and the request clearly.
- Decide whether approval is needed.
- Route to the right approver based on real patterns or configured rules.
- Make the license or access change in the right system.
- Update the PSA ticket with what was granted and where, so a leaver ticket can reverse it later.
- Tell the user what changed and what to do next.
The list looks obvious, but most tools handle one or two of those steps. That's why teams stay in swivel-chair mode: one app reads, another routes, a human approves in chat, a tech makes the change in a vendor console, and someone documents it later. If you want to see tighter execution in practice, see how Rallied AI works.
Keep human judgment where it belongs
Not every ticket type should run autonomously on day one, and not every approval should be bypassed. The better model is scoped autonomy: let routine, low-judgment work move fast, keep approval gates where they matter, review outcomes in the first couple of weeks, and expand based on what you learn. That avoids paralysis from overdesign and chaos from overtrust.
Some teams prefer stricter gating at the start, which is reasonable if they've been burned before. Decide up front what an agent is allowed to touch in each client tenant, as covered in AI agent permissions for MSPs. Eventually you need a system that can act, though, or you've rebuilt the same bottleneck in newer software.
The work also has to span the stack your techs already use: PSA, chat, identity, RMM when needed, documentation, and the admin consoles that don't have clean APIs. If your provisioning plan only works where APIs are perfect, it's too narrow for real client environments. Learn more about Rallied AI
Where Rallied fits in multi-system user provisioning
Rallied is an AI agent that closes MSP tickets in the PSA. It works tickets in ConnectWise, HaloPSA and Autotask, runs the fix in Microsoft 365 and your RMM (including NinjaOne), and writes the notes and time entry back to the ticket. During triage it pulls the client's documentation from IT Glue or Hudu, so the context a tech would go looking for is already on the ticket.
It works inside the systems it is connected to. If a step lives in a line of business app outside that list, a tech still does that step, which is why mapping each client's apps (the SCIM section above) is worth doing first.
You set up the integrations, workflows and policies that decide what Rallied may act on, and that setup is never charged. Pricing is one plan at $300 a month with 2,000 credits, and each ticket is charged once for the most work done on it: 1 credit for work on the ticket itself, 3 credits for looking up or changing things in another system, and 8 credits for work across three or more systems using six or more actions, or running a script. A ticket it couldn't finish or wasn't allowed to act on is not charged. Full details are on the pricing page.
If your team is tired of automation projects that turn into a side job, get started with Rallied AI. To see how Rallied handles Microsoft 365 tickets inside your PSA, read about Microsoft 365 Management for MSPs. For the wider picture, read how MSPs automate user onboarding.
Frequently Asked Questions
What is multi-system user provisioning?
User provisioning is creating accounts and granting the right access across every system a person needs, then updating and removing that access as their role changes or they leave. For an MSP it usually spans Microsoft 365 or another identity provider, line of business apps, the RMM, documentation and the PSA ticket. The joiner/mover/leaver process describes the three moments it has to happen.
What are the most common mistakes in multi-system user provisioning?
The usual ones are mapping only the happy path, treating approvals as a clean policy tree, assuming SCIM covers every app, cloning roles without reviewing them, and handling deprovisioning from memory. Another is buying a tool that summarizes or routes the request while a technician still makes the change by hand.
Does SCIM solve provisioning across all of a client's apps?
No. Microsoft Entra ID offers separate connector paths for SCIM, LDAP, SQL, REST and SOAP services, flat files and custom connectors because apps differ. Even SCIM support can be partial: Atlassian syncs groups for Jira, Confluence and Trello but not yet for Bitbucket.
Why does deprovisioning matter as much as provisioning?
Dormant accounts can be gateways to data breaches even when the former user means no harm. Provisioning failures often show up as access lingering after role changes or former employees keeping access. Recording every grant on the joiner ticket makes it possible to reverse each one on the leaver ticket.
Should MSPs automate approvals for software and access requests?
Automate the routing, but keep approval gates where they matter. Building the first version from who actually approved past requests in your ticket history works better than designing a policy tree from scratch. Send ambiguous or weak-signal requests to a human for confirmation.
How does Rallied charge for provisioning tickets?
Rallied is $300 a month with 2,000 credits included, and each ticket is charged once for the most work done on it. Work across three or more systems with six or more actions, or running a script, is 8 credits, while a single change in another system is 3. Tickets it couldn't finish or wasn't allowed to act on are not charged.