How to Route Approvals to the Right Manager with Microsoft Entra ID and Jinba

Summary

• Access request workflows in regulated enterprises break down when teams manually find the requester's manager, causing stalled tickets, wrong inboxes, and missing audit context.
• Microsoft Entra ID's native admin consent workflow routes to a static reviewer list, while Entitlement Management supports manager routing but lacks a unified end-to-end view.
• A four-stage workflow consisting of trigger, Entra ID manager lookup, direct-manager approval, and unified audit logging eliminates misrouted requests and makes the directory the authority.
• The manager lookup uses least-privilege User.Read.All delegated permission, handles missing managers with a fallback group, and supports skip-level approvals via $expand=manager($levels=n).
• Jinba Flow provides this orchestration layer with documented audit trails, so enterprises can route approvals from Entra ID without custom scripting.

In regulated enterprises, access request workflows frequently fail at the same point: identifying the correct approver. When a new hire needs application access or a provisioning request is submitted, operations teams must manually determine the reporting manager, locate the contact details, and forward the request. In organizations with frequent role changes or users spread across multiple directory domains, that lookup is error-prone and slow.

The operational pattern is well established among IT and HR teams. Tickets sit unassigned while prerequisite steps complete. Requests land in the wrong inbox. When the correct approver is eventually reached, there is no centralized record of what was requested, who looked up the manager, or what was decided.

This guide details a four-stage workflow in Jinba that resolves this using Microsoft Entra ID integration. The workflow triggers on an HR or access request, enriches it with live directory data from Entra ID, routes the approval to the correct manager automatically, and logs every step for audit purposes.

Why Entra ID's Built-In Consent Workflow Does Not Solve This

The native admin consent workflow in Microsoft Entra ID routes requests to a static list of designated reviewers. Those reviewers are configured in advance and do not change based on who submitted the request. The workflow does not resolve the requester's manager from their directory profile.

This is the structural limitation. A blanket policy that routes all consent requests to a fixed group produces accurate results only when that group is always the right approver. For onboarding flows, provisioning requests, and access packages, the correct approver is almost always the requester's direct manager, which is a relationship that lives in the directory and changes as the organization changes.

Entitlement Management supports routing access-package approvals to the requestor's manager and requires fallback approvers for cases where no manager attribute is set. Lifecycle Workflows contribute audit logs and can trigger on HR-driven attribute changes such as employeeHireDate. However, neither tool provides a single, unified view of the full process from trigger through lookup to final decision. That orchestration requires an external workflow layer.

Stage 1: Trigger

The workflow begins when an HR system, ticketing platform, or service desk submits a request. Common triggers include:

• A new hire record created in an HR system, passed to Jinba via webhook
• An access package request initiated through Entitlement Management
• A ServiceNow ticket opened for software provisioning

Lifecycle Workflows can serve as a structured trigger for Joiner-Mover-Leaver scenarios. They activate on user attribute changes and can initiate downstream steps such as emailing a manager before a new hire's start date. Note that Lifecycle Workflows require a Microsoft Entra ID Governance or Entra Suite license.

For most organizations, a webhook trigger in Jinba accepting a payload from the HR or ITSM system is the most direct path. The payload carries the requester's user principal name (UPN) or email address, which becomes the input to the enrichment step.

Stage 2: Enrich with the Microsoft Users Tool

The Microsoft Users tool handles the Entra ID lookup. The tool calls the Microsoft Graph API endpoint GET /users/{id|userPrincipalName}/manager, which returns the full user object for the assigned manager, including display name, email address, and job title.

The lookup is a standard Graph API call. Standard APIs of this type are included within documented usage thresholds for user subscriptions and carry no additional per-call fee, as confirmed in the Microsoft Graph metered API overview.

Two edge cases require explicit handling in the workflow configuration.

No manager assigned. If the requester's Entra ID profile has no manager attribute set, the Graph API returns HTTP 404 Not Found. This is a documented behavior, not an error in the integration. A conditional branch after the lookup step must check for this response and route the request to a fallback group, typically an HR or IT administrator channel in Teams or Slack.

Skip-level routing. When an approval needs to escalate above the direct manager, the Graph API supports fetching multiple levels of the reporting chain using GET /users/{id}/?$expand=manager($levels=n), where n is a number between 1 and 1000, or max. This query requires the ConsistencyLevel: eventual request header. Jinba's Microsoft Users tool exposes this as a configurable parameter, so skip-level routing does not require custom scripting.

Permissions and Least Privilege

Before configuring the enrichment step, IT teams must confirm the correct permission scope is in place. The Microsoft Graph permissions model separates delegated permissions, which act on behalf of a signed-in user, from application permissions, which act as a background service.

For the GET /users/{id}/manager endpoint, the required permission is the delegated permission User.Read.All. Application permission is not supported for this specific endpoint. A background service using an app-only token cannot call this API. Jinba's connector handles the delegated authentication flow, so this constraint does not require additional configuration from the implementing team, but it does need to be understood when the tenant administrator grants consent.

Applying least privilege:

• Use User.Read.All rather than Directory.Read.All. The Directory.Read.All permission grants significantly broader read access across the directory. Microsoft explicitly advises using it with caution.
• Granting User.Read.All requires consent from a Privileged Role Administrator or Global Administrator.
• Configuring approval policies within Entitlement Management requires at least the Identity Governance Administrator role.

These role requirements ensure that the connection between Jinba and Entra ID is established through a controlled, auditable process rather than through ad-hoc individual consent.

Stage 3: Route the Approval

Once the manager's profile is returned, the workflow sends an interactive approval request using Jinba's Slack or Microsoft Teams tool. The message is constructed from data already in the workflow: the requester's name and details from the trigger payload, the resource being requested, and the manager's display name and email from the enrichment step.

The approval message includes action buttons for Approve and Deny. The workflow pauses at this step and waits for a response before proceeding. No manual intervention or ticket reassignment is needed.

For organizations running cross-domain directory structures, where users in one domain report to managers in another, the Graph API returns the manager object regardless of which domain they reside in, provided the manager attribute is correctly populated in Entra ID. Keeping that attribute current is a directory hygiene requirement, not a limitation of the workflow.

Stage 4: Log the Full Audit Trail

Every step of the workflow execution is recorded in Jinba's audit log. This includes:

• The trigger event and the payload it carried
• The exact manager lookup performed, including the UPN queried
• The result returned: manager found, or 404 with fallback routing applied
• The approver's identity, their decision, and the timestamp
• Any downstream action executed following the decision, such as provisioning confirmation or ticket status update

This unified record addresses a specific gap in native Entra ID tooling. Entitlement Management records time-boxed decisions and approver justifications. Lifecycle Workflows capture workflow history and audit logs. Neither provides a consolidated view across trigger, lookup, notification, and decision. Jinba's log covers the full chain in a single place, which is the record that compliance teams and auditors require.

Building the Workflow in Jinba

The configuration sequence in Jinba follows the four stages directly:

1. Create the workflow and select a trigger. Use a Webhook trigger to receive the HR or ITSM payload, or connect directly to a supported source such as ServiceNow.
2. Add the Microsoft Users tool. Select the "Get user's manager" action. Map the requester's UPN or email from the trigger payload to the User ID input field.
3. Add a condition step after the lookup. Check whether the manager output is empty or contains an error. If no manager is found, route to a designated fallback channel. If a manager is found, continue to the approval step.
4. Add the Teams or Slack tool on the primary path. Use the "Send a message with action buttons" action. Map the manager's email from the Microsoft Users output to the recipient field. Compose the request message using fields from the trigger payload, and add Approve and Deny buttons.
5. Add decision-handling steps. Configure what happens after each response: provisioning runs, the ticket updates, or a denial notification goes back to the requester. The workflow log captures the full execution automatically.

What This Workflow Delivers

Routing approvals through Entra ID directory data changes the structure of the process, not just its speed.

The organization chart in Entra ID becomes the authoritative source for every routing decision. When a manager changes, the next approval automatically goes to the new manager. No workflow rules need updating. No tickets get misrouted because a distribution list is stale.

The permission model is explicit and auditable. The User.Read.All delegated scope is the narrowest permission that supports the lookup, and it is granted through a controlled admin consent process. Every lookup that scope enables is recorded.

The fallback condition ensures that requests with missing manager attributes do not stall or disappear. They route to a defined group and remain visible. This is the same pattern that Entitlement Management enforces natively: fallback approvers are required, not optional.

For regulated enterprises, the audit log produced covers the full chain from request to decision. That record is available without correlating logs across multiple Microsoft services.

Explore Jinba's Microsoft Users tool to start configuring manager-based approval routing against your Entra ID directory.

Frequently Asked Questions

What is the Microsoft Graph API endpoint for retrieving a manager in Entra ID?

The endpoint is GET /users/{id|userPrincipalName}/manager. It returns the full manager user object, including display name, email address, and job title. Jinba's Microsoft Users tool calls this endpoint automatically during the enrichment stage.

Does the built-in Microsoft Entra ID admin consent workflow route requests to the requester's manager?

No. The native admin consent workflow routes all requests to a static list of designated reviewers. It does not resolve the requester's manager from directory data. Jinba resolves the manager dynamically from Entra ID, so requests go to the correct approver even when reporting lines change.

What permission is required to call the manager lookup API in Microsoft Graph?

The delegated permission User.Read.All is required for GET /users/{id|userPrincipalName}/manager. Application permissions are not supported for this endpoint. Using User.Read.All rather than Directory.Read.All follows least privilege and reduces directory exposure.

What happens if a user has no manager assigned in Entra ID?

The Microsoft Graph API returns HTTP 404 Not Found. A conditional branch in the Jinba workflow detects this response and routes the request to a fallback group, such as HR or IT administrators. This prevents requests from stalling when the manager attribute is missing.

How are skip-level approvals implemented using Entra ID manager data?

Microsoft Graph supports fetching multiple levels of the reporting chain with GET /users/{id}/?$expand=manager($levels=n), where n can be between 1 and 1000 or max. The request must include the header ConsistencyLevel: eventual. Jinba exposes this as a configurable parameter, so skip-level routing does not require custom scripting.

Can a background service use app-only permissions to look up a manager in Entra ID?

No. The manager lookup endpoint only supports delegated permissions, meaning the call must be made on behalf of a signed-in user. An app-only token with application permissions cannot call GET /users/{id|userPrincipalName}/manager. Jinba handles the delegated authentication flow on behalf of the organization.

What Microsoft licensing is required to trigger Joiner-Mover-Leaver workflows from Entra ID Lifecycle Workflows?

Microsoft Entra ID Lifecycle Workflows require a Microsoft Entra ID Governance or Entra Suite license. However, if an organization's HR or ITSM system sends a webhook directly to Jinba, the same manager-based approval workflow can be triggered without that specific license.

How does Jinba's workflow differ from Microsoft Entitlement Management for access package approvals?

Entitlement Management can route access package approvals to the requestor's manager and requires fallback approvers, but it does not provide a single unified view across trigger, lookup, notification, and final decision. Jinba orchestrates the full chain and logs every step in one consolidated audit trail.