Shift-left on the service desk: what to automate first

Shift-left is one of the most quoted ideas in service desk strategy, and one of the vaguest. This post makes it concrete: what shift-left is, why it works, and which work you move left first on a Microsoft service desk.

TL;DR

• Shift-left means resolving work at the earliest and cheapest point in the chain.
• On a service desk that order is: rules, self-service, first line, second line, specialist.
• Start with repeatable access and license work, because it has volume and a clear pattern.
• Access that follows an attribute (department, job title, location) can run on rules, without a ticket.
• Keep sensitive and exceptional requests deliberately with a human.

What shift-left is

Shift-left comes from the idea that support is a chain. Far left sits the user who helps themselves. Then an automated rule or a self-service portal. Then the first line, the second line, and far right the expensive specialist.

Every step to the right costs more time and money. A request handled by a specialist costs a multiple of the same request handled by a rule. Shift-left is simply this: make sure work gets resolved as far left as possible.

Important: shift-left is not a tool, it is a direction. You move work, not by working harder, but by organizing the work differently.

Why a Microsoft service desk has so much to gain here

On a Microsoft service desk, a large share of the daily work is identity and access. Someone wants a shared folder, a new colleague needs the standard apps, someone moves to another department. Those are exactly the requests with high volume and a predictable pattern, which makes them the best place to start shift-left.

The pattern is almost always the same: an attribute determines the access. Department, job title, or location. As soon as an attribute determines access, you can turn it into a rule instead of a ticket.

The order in which you move left

Not everything at once. Use this order, from most to least suitable to move:

Layer	What it handles	Suitable to move
Rules	Access that follows an attribute	Yes, first
Self-service	Requests with a fixed flow and approval	Yes
First line	Questions that need explanation or a check	Partly
Second line	Configuration, troubleshooting	Limited
Specialist	True exceptions, sensitive rights	Keep here on purpose

The biggest gain sits in the top two rows. That is where the volume runs and where automation works cleanest.

What to automate first

Start with access that has high volume and low risk:

1. Standard department access. Everyone in Sales gets the Sales tools. High volume, clear pattern.
2. Role-based apps and groups. Follows the job title, so predictable.
3. Location-based rights. Follows the city or office.

These three together are often the bulk of access requests. By capturing them in rules, you resolve them on the left of the chain, before a ticket even exists.

An example in Entra ID terms:

user.department -eq "Sales" -> member of Sales-Apps
user.jobTitle -contains "Engineer" -> member of Engineering-Tools
user.city -eq "Enschede" -> member of Office-Enschede

When someone changes department, the membership changes with them. The ticket you used to get no longer needs to be opened.

What you deliberately do not move left

Shift-left does not mean everything left. Two categories belong with a human:

• Sensitive rights. Admin access, financial systems, executive files. Here you want a deliberate human approval.
• True exceptions. A contractor with a special arrangement, a temporary extension. Put those in a separate static group, away from your rules.

By moving the boring volume left, you keep time for the work where judgment really matters.

How ServiceChanger fits in

ServiceChanger applies group and role memberships across Entra ID and on-prem AD based on rules (ABAC). You define which access belongs to which department, job title, or location, and ServiceChanger keeps the membership correct and keeps it correct over time. That is shift-left in practice: the access follows a rule, not a ticket.

The License module tracks license usage based on Entra sign-in activity, so you can see which licenses are actually used. The actual assignment of licenses stays with Microsoft. By default ServiceChanger works on 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.

FAQ

Is shift-left the same as automation? Not quite. Shift-left is the direction (resolve work as far left as possible). Automation and self-service are two of the ways to do it.

Where do I start if I have little time? With standard department access. High volume, low risk, clear attribute pattern. That gives you results fastest.

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

How do I know the rules are correct before they go live? Run the rules next to your current situation first and compare who the rule picks up versus who is in the group now. Adjust the differences, then go live.

Further reading

• Service desk automation: stop handling access requests by hand for the practical build.
• Scale your service desk without growing headcount for the capacity side of the same story.

Next step

Want to move repeatable access work left on your Microsoft service desk? ServiceChanger automates group and role membership based on rules. Book a demo or read the ABAC docs.