The request queue is the heartbeat of a support-approved EPM deployment, and the first build sheet left it beating under whoever happened to hold broad Intune rights. This build gives the queue proper owners without giving them the tenant: a scoped role, a deliberate workflow, and a cadence that lives somewhere more durable than goodwill.
Step 1: The Approver Group
Create a user group for the people who will work the queue – SEC-EPM-Approvers, assigned membership. Two properties of this group are worth stating plainly. Approvers need no EPM license: the license follows the users being managed, while approval rights follow the Intune role you are about to build, and the two never need to overlap. And the group should be small and named, because every approval enters an audit record, and an audit record is only as meaningful as the shortness of the list of people who could have written it.
Step 2: The Scoped Role
Intune RBAC lives under Tenant administration, and the piece that matters here is a single permission category: Endpoint Privilege Management Elevation Requests. Build a custom role that holds it and nothing else. The built-in roles that happen to include it carry far more alongside, and the entire point of this build is that approving elevations is a helpdesk-shaped task which should not require helpdesk staff to hold policy-editing power.
| Role element | Value | Why |
|---|---|---|
| Role type | Custom role, e.g. EPM Elevation Approver | Purpose-built and legible in an audit. Nobody has to wonder what this role is for or why someone holds it. |
| Permission | Endpoint Privilege Management Elevation Requests – view and manage rights | View lets an approver read the queue; manage lets them decide it. Nothing else in Intune comes along. |
| Everything else | Not granted | Approvers do not need to edit EPM policies, and the people who edit EPM policies do not automatically need to work the queue. Separating the two is the design. |
Step 3: The Role Assignment
An Intune role assignment has three parts, and all three are decisions rather than formalities. The admin group is SEC-EPM-Approvers – who holds the rights. The scope groups define whose requests those rights reach: for the pilot, a group holding the pilot personas; at scale, this is where a regional or divisional helpdesk gets a queue that contains only its own people. Scope tags apply if the wider RBAC design uses them, and follow whatever that design says. The pilot needs one assignment; the shape you just built is the one that grows.
Step 4: Working the Queue
The queue itself is the Elevation requests tab on the EPM node. Each request carries the file details, the publisher, the requesting user, and the business justification they typed. The decision discipline looks like this:
| Signal | Action | Why |
|---|---|---|
| Reasonable request, recognizable file, plausible justification, first occurrence | Approve, with a written reason | The grant is narrow – that user, that file, twenty-four hours from approval – so a generous approval costs little and keeps the user inside the mechanism. |
| Same file appearing repeatedly, from one user or several | Approve, and flag the file for rule promotion | Repetition is the pilot’s product. The rules build sheet turns this flag into a durable rule so the queue stops carrying it. |
| Unknown publisher, justification that does not parse, or a file that has no business elevating | Deny, with a written reason | The reason enters the audit record and reaches the user. A deny with a clear reason teaches; a silent deny breeds workarounds. |
Remember what an approval is: a twenty-four hour window for one user and one file, starting when you click, with no early revocation. If you are hesitating over whether something should be approved at all, that hesitation is the answer – deny it and let the conversation happen outside the queue.
One property of the requester side is worth stating because it decides whether this works on shared hardware: a support-approved request can come from any user of a device, not only the person it enrolled under. That is what makes the workflow viable on multi-user and kiosk machines, where whoever hits the elevation is rarely the primary user.
Step 5: The Cadence
Intune sends no notification when a request arrives, so the cadence has to be structural. During the pilot, the queue gets checked several times a day, and the practical way to make that real is to attach it to something that already happens – the start of a helpdesk shift, the ticket-queue sweep, the standup. In steady state, approval latency is the metric that decides whether the mechanism survives: users who get answers in minutes keep asking, users who wait a day stop. Set an internal service level for the queue the same way you would for a priority ticket class, staff it accordingly, and watch the request volume from the rollout article as the signal that the staffing still matches the population. The queue that this build sheet constructed feeds directly into the next one: the repeated requests you flagged are the raw material, and the rules build sheet turns them into policy.
Intune Deployment Guide · Phase 12: The Intune Suite
‹ Previous: [12.2.4] Build Sheet: The Elevation Settings Policy and the Pilot
Next: [12.2.6] Build Sheet: Elevation Rules ›
