ITIL request fulfilment without the ticket: a Microsoft approach

In ITIL, request fulfilment is the process that handles standard service requests: a new employee who needs access, someone requesting an application, a rights change. A large part of those are about access, and that part can be handled by rules instead of tickets. This post explains the mapping.

TL;DR

• Request fulfilment in ITIL handles predictable, repeatable service requests.
• A large share of those requests are about access and follow an attribute.
• What follows an attribute can be modeled as a rule in Entra ID, without a ticket.
• The process stays, only the execution shifts from manual to rule-driven.
• Keep approval and exceptions in the process, where judgment is needed.

What request fulfilment is in ITIL

Request fulfilment is one of the processes in service operation. It is not about failures (that is incident management) but about standard requests that occur often and have a known way of being handled. Think access to a system, a software license, a change in membership.

The core is that a service request is predictable. It fits a catalog, has a fixed route, and often a predetermined approval. That is exactly what makes it suitable for automation: predictable work with a known pattern.

Why access is the ideal place to start

Look at the service requests that come in most often, and they are usually access requests. A new colleague needs the standard access, someone changes department, someone wants a shared resource.

In almost all of those cases an attribute determines the outcome. The department determines which apps, the job title determines which roles, the location determines which local rights. And when an attribute determines the outcome, no human needs to sit in between to decide it.

The mapping: from process to rule

The ITIL process stays. What shifts is the execution. Instead of an employee looking up the right group per ticket and making the change, you capture the logic in a rule.

ITIL request fulfilment	Manual execution	Attribute-driven execution
Standard access for new employee	Ticket, human finds group	Rule on department and job title
Role change	Ticket, human adjusts membership	Attribute changes, membership follows
Location-based right	Ticket	Rule on city or office
Access to sensitive system	Ticket with approval	Approval stays, human decides

The first three rows shift to rules. The last stays in the process deliberately, because that is where judgment counts.

What it looks like in Entra ID

In Entra ID terms the pattern becomes a membership rule. A few examples:

user.department -eq "Finance" -> member of Finance-Apps
user.jobTitle -contains "Controller" -> member of Controllers
user.city -eq "Lichtenvoorde" -> member of Office-Lichtenvoorde

When a new Controller in Finance in Lichtenvoorde arrives, the rules pick that up without anyone opening a ticket. The request is fulfilled the moment the attributes are correct.

When someone later changes role, the membership changes with them. The rights that no longer fit fall away without anyone having to file a separate request for it.

What stays in the process

Not everything becomes a rule. What stays in the ITIL process:

• Approval for sensitive access. Admin rights, financial systems. There you want an explicit approval.
• Exceptions. A request that does not fit the pattern belongs with the service desk.
• The catalog itself. What is requestable and under which conditions stays a deliberate choice.

That way you automate the predictable part of request fulfilment and keep judgment where it belongs.

How ServiceChanger fits in

ServiceChanger applies group and role memberships across Entra ID and on-prem AD based on attributes (ABAC). That makes it the execution layer under the part of request fulfilment that follows an attribute: you define the logic, and the membership is correct and stays correct.

ServiceChanger works on the attributes already in your directory, within Microsoft and Azure. The License module tracks license usage based on Entra sign-in activity; the assignment of licenses itself stays with Microsoft. By default ServiceChanger reacts to the attributes already in your directory. 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. For AI-driven ticket handling there is ITSM Autopilot, our sister product.

FAQ

Does this replace my ITSM tool? No. The ITIL process and your service desk tool stay. ServiceChanger takes over the execution of access work for the requests that follow an attribute.

What about approval flows? You keep them. For sensitive access, a deliberate human approval stays part of the process.

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

How do I know a rule does the right thing? Run the rule 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

• What is ABAC in Entra ID for the membership rules in detail.
• Service desk automation: stop handling access requests by hand for the practical build.

Next step

Want the predictable part of request fulfilment handled by rules? ServiceChanger automates group and role membership in Entra ID based on attributes. Book a demo or read the ABAC docs.