Track your IT ticket queue for one month and you will find them: a handful of request types that arrive like clockwork, follow the same decision path every time, and require almost no judgment to resolve. Mine were software access requests, VPN and remote access provisioning, offboarding task triggers, new device setup coordination, and password reset escalations that bypassed the self-service portal. Together they made up roughly 60% of my queue. Not one of them needed me to think.
The problem with repetitive tickets is not just the time they consume per ticket. It is the context-switching cost. Every time I pulled one off the queue, I re-read the same fields, confirmed the same approvals, ran the same steps, and sent the same confirmation message. Multiply that by the volume and the real cost is what I was not doing while I handled the predictable ones: root-cause work, proactive fixes, the tickets that actually required judgment.
Over about six weeks I built five Power Automate flows in our Microsoft 365 environment, one for each request type, using Microsoft Forms for intake and the M365 Approvals connector for routing. Here is the full playbook.
The Pattern Behind All Five
Before going flow by flow, the most useful thing I learned was this: every one of these requests follows the same four-stage structure. Intake (a Microsoft Form with only the fields needed to decide), route (a condition block in Power Automate sends it to the right person or queue), act (the Approvals connector fires a Teams card or a SharePoint task), and notify (the requester hears back on receipt and on resolution). Once you understand this pattern, the fifth flow takes a fraction of the time the first one did.
Flow One: Software Access Requests
This was the highest-volume request type in my queue and the fastest to automate. Before the flow, a software access ticket meant reading the request, confirming with a manager, checking whether we had a licence available, creating the access, and emailing the user. Roughly 8 to 10 minutes of handling per ticket, spread across two or three touch points.
The intake form captures: requester name, department, software name, business justification (one line), and a yes/no on whether they already have manager sign-off.
Power Automate does four things from there:
- Checks whether the requested software is on the pre-approved list (a SharePoint list I maintain)
- If yes, routes directly to the application owner with a one-click Approvals card in Teams
- If no, escalates to IT leadership before any provisioning happens
- On approval or rejection, sends the requester a Teams notification with the outcome and expected timeline
The pre-approved list is the key lever. The first time I built it I spent an hour reviewing the past six months of access tickets and identifying every software title that had been approved at least five times with no rejections. Those go on the list. Everything else still routes to IT leadership, but it arrives with full context attached instead of a bare email saying "can I have access to X."
Flow Two: Offboarding Checklist Triggers
The offboarding flow solved a different problem. It was not volume, it was risk. A missed offboarding step is a security gap: a former employee with active credentials, a shared mailbox that never gets handed off, a licence that keeps billing for someone who left six months ago. Before this flow existed, we caught near-misses by memory, which is not a process.
HR submits a Microsoft Form with the departing employee's name, last day, department, and a checklist of access categories (standard, elevated, admin, or shared account). Power Automate creates a task list in SharePoint automatically, assigns each task to the correct IT team member, sets due dates based on the last day, and posts a summary card to the IT channel in Teams.
The rule I enforce: no offboarding ticket closes until every task in the list is marked complete. Power Automate sends a daily reminder to any open item owner until it is resolved. The human judgment is not removed, it is structured. Every step has an owner and a deadline, and nothing falls through the gap between two people who each assumed the other handled it.
The automation handles the choreography, not the keys. A human on the IT team executes each deprovisioning step and checks it off. The flow is the accountability layer, not the actor.
Flow Three: Password Reset Escalation
Most users try self-service first, which is exactly what you want. The problem is the fallback path when self-service fails. Before this flow, a blocked user had two bad options: email a general IT address and wait for someone to notice, or call a desk line that was not always staffed. Neither option gave them any visibility into whether anyone was working on it.
The intake form is a three-field form embedded in the internal IT portal: username, a short description of what they tried, and their manager's name for identity verification purposes.
Power Automate routes it to the IT queue with the user's context already attached, creates a ticket in the helpdesk system via the REST API connector, and sends the user a Teams message confirming receipt and expected response time.
The reset itself is manual because account resets require identity verification. That step stays with a human. But the ticket arrives with context, the user knows someone is on it, and the queue has a real record rather than a floating email thread. Average handling time on these dropped by roughly half once the intake noise was gone.
Flows Four and Five: VPN Access and Device Setup
The VPN and remote access flow adds one check before routing to approval: it verifies the requester's employment status and device compliance state in Intune. If either check fails, the flow creates an informational ticket instead of an approval request, so IT investigates before any credentials are issued. That single condition has caught provisioning requests that would have gone through automatically under the old email-based process.
The new device setup flow is a coordination tool rather than an approval chain. HR submits a form when a start date is confirmed, and Power Automate creates a SharePoint task list covering imaging, software, security config, licence assignment, and delivery, each assigned to the right IT team member with a due date. When complete, the new user gets a Teams message that their device is ready. Nothing in the provisioning itself is automated. The flow handles the tracking.
What Actually Changed
After running all five flows for about two months, the administrative overhead on those request types dropped by roughly 40%. More importantly, the tickets that actually need my attention became easier to find. When you clear the repetitive layer off the queue, the hard cases surface faster.
The intake form does something else worth noting: it enforces the right questions upfront. Nobody submits a software access request without stating why they need it. The percentage of these tickets that resolve with zero back-and-forth after initial submission is now consistently above 80%, against roughly one in three before the flows existed.
Where to Start
If you are running M365 and have not built any of these flows yet, start with the software access request flow. It handles the most volume, teaches the four-stage pattern, and uses the Approvals connector, which is well-documented. Build it manually rather than importing a template. You will understand the condition logic better if you wire it yourself, and that understanding transfers to the next four flows faster than you expect.
A few things worth knowing before you start:
- Use the Approvals connector, not just email. Email-based approval chains break when someone is out of office. The Approvals connector in Teams keeps the decision in the queue and reroutes if needed.
- Keep the intake form short. Four to six fields maximum. Every extra field you add reduces submission rate and increases the chance someone calls you instead of submitting the form.
- Do not automate the provisioning step until you have reviewed the blast radius. Routing and tracking can be fully automated. Access changes that touch Entra ID, Intune, or privileged systems should stay behind a human approval until you have high confidence in the logic.
- Build your pre-approved list incrementally. Start with the five most common approvals from the last quarter. Add to it every time a new request gets approved three times with no variation.
Microsoft Learn covers the Forms and Approvals connectors well. Community templates are useful as reference, not as finished builds. Read them to understand what is possible, then wire your own so you can maintain it without reverse-engineering someone else's logic later.
If you are building something similar and want to compare notes on your queue data, drop me a message.
Comments