Automate the service desk: stop handling access requests by hand

A large share of what a service desk does every day is arrange access. Someone wants a shared folder, a new hire needs the standard apps, someone changes department. Each one a ticket, each one manual work. Most of it does not need a human. This article shows what to automate first and how.

TL;DR

• Access requests are often a quarter to half of ticket volume and almost all manual.
• Most of it follows a pattern: department, job title, or location decides the access.
• Tie each department, job title, or location to a bucket of groups, so membership is correct automatically.
• Start with the standard access that comes with each department or job title.
• Keep exceptions and sensitive rights deliberately with a human.

Why access requests cost so much time

An access request looks small, but the real cost sits in the chain around it: reading the ticket, judging whether it is allowed, finding the right group, making the change, reporting back, and asking someone for approval when in doubt. Count on 10 to 20 minutes per request, times dozens per week.

Worse is what does not happen: rights that stay in place after someone changes role. Nobody opens a ticket to remove access. That is how the silent pile of rights grows, things people have and should no longer have.

The pattern behind most requests

Look at a week of access requests and you will see the majority follows a pattern. Someone in Sales wants the Sales tools. A new engineer wants the standard engineering access. Someone moves to the Enschede office and needs the local rights.

In all of these cases one attribute decides the access: department, job title, or location. And such an attribute usually comes with more than one group, it comes with a whole set. Sales, for example, needs the Sales CRM, the shared Sales drive, the VPN, and the M365 license group. So think of an attribute value as a bucket: one label that holds a fixed set of groups together.

What to automate first

Not everything at once. Start with the access that has the highest volume and the lowest risk:

Type of access	Automate?	Why
Standard department access	Yes, first	High volume, clear attribute pattern
Job-tied apps and groups	Yes	Predictable, follows the job title
Location-tied rights	Yes	Follows the city or office
Temporary project access	Partly	Can run through a separate rule or static group
Admin and executive rights	No	Sensitive, keep deliberately manual

The first three rows are where most time leaks away and where rules take over the work.

One attribute, a bucket of groups

The shift is conceptually small but large in practice. Instead of ticking off individual groups per person, you tie each department, job title, or location once to the bucket of groups that belongs with it:

Department = Sales    ->  Sales-CRM, Sales-Drive, VPN, M365-Sales
Department = IT       ->  IT-Admin, Servicedesk, VPN, M365-IT
Job title  = Manager  ->  Approvers, Reporting, Management-Dashboard

Set an employee's department to Sales and they get the whole Sales bucket at once. Move them to IT and the Sales bucket drops, the IT bucket takes its place, and the groups that no longer apply are cleaned up. New hires are covered straight away: set the attribute and the right access follows. The ticket you used to get to remove access is one nobody needs to open anymore.

What to keep deliberately with a human

Automating does not mean automating everything. Two categories you want to keep manual on purpose:

• Sensitive rights. Admin access, executive files, financial systems. Here you want a human who deliberately approves.
• Real exceptions. A contractor with a special arrangement, a temporary extension. Put those in a separate static group, apart from your rules.

That way you automate the boring volume and keep control where it matters.

What ServiceChanger does here

ServiceChanger automates group and role memberships in Entra ID and on-prem AD. Concretely that means: you tie each department, job title, or location to a bucket of groups, and ServiceChanger makes sure the membership is correct and stays correct.

By default ServiceChanger reacts to the attributes already in your directory, within Microsoft and Azure. If you want to connect your HR system for onboarding and offboarding, we build that as custom work using automation accounts and runbooks in Azure. The actual assignment of licenses stays with Microsoft; ServiceChanger manages access and reports on license usage.

FAQ

Does this replace my service desk tool? No. It takes the most repetitive access work out of the ticket stream, so your support team is left with the work where people are genuinely needed.

How do I make sure the rules are right before they go live? Place the rules alongside your current situation first and compare who the rule picks up versus who is in the group now. Fix the differences, then go live.

Does this also work for my on-prem Active Directory? Yes. ServiceChanger applies rules to both Entra ID and on-prem AD, so a hybrid environment falls under one model.

What about access nobody needs anymore? That is exactly the win. Because membership hangs on the rule, access disappears automatically when the attribute changes. No more silent pile of rights.

Further reading

• Self-service portal for access for letting people request access with an approval flow.
• IT offboarding checklist for what happens to access when someone leaves.

Next step

Want to take the manual access work out of your service desk? ServiceChanger automates group and role membership in your Microsoft environment based on rules. Book a demo or read the ABAC docs.