Build PIM eligible role assignment configs with schedule, activation rules, approval workflows, and notification settings.
Build PIM eligible role assignment configs with schedule, activation rules, approval workflows, and notification settings.
Required Fields
roleNameprincipalIdprincipalTypeassignmentTypescheduleInfo.startDateTimescheduleInfo.expiration.typeactivationRules.maximumActivationDurationOutput will appear here...Build an Entra ID Privileged Identity Management eligible role assignment with a time-bound schedule, activationRules requiring approval/justification/MFA/ticket-info before a user can actually invoke the eligible role, and separate notificationSettings for the eligibility-grant event versus the activation event. assignmentType: Eligible (versus Active) is the entire point of PIM, an eligible assignment grants no standing access at all, the principal must explicitly activate it (satisfying activationRules) each time they need the permissions, and maximumActivationDuration then bounds how long that activated, elevated access actually lasts before automatically expiring back to eligible-only.
No, an eligible assignment by itself grants zero standing access, the principal can see they're eligible for the role but cannot use any of its permissions until they explicitly go through PIM's activation flow and satisfy whatever activationRules are configured (approval, MFA, justification). This is the fundamental difference from an Active assignment, which grants standing access with no activation step required at all.
The activated, elevated permissions automatically expire and revert the principal back to eligible-only status, they'd need to go through activation again (satisfying activationRules again) to regain the elevated permissions. This is a hard automatic timeout, not a warning, work relying on the elevated permissions needs to either complete within the window or the user needs to proactively reactivate before or after expiry.
It applies to the eligible assignment itself, the underlying grant of eligibility, not to any single activation session (that's what maximumActivationDuration under activationRules controls instead). A 90-day AfterDuration expiration on scheduleInfo means the person stops being eligible for this role at all after 90 days, regardless of how many times they activated it during that period, requiring a fresh assignment decision afterward rather than indefinite eligibility.
The builder validates that roleName, principalId, principalType, assignmentType, scheduleInfo.startDateTime, scheduleInfo.expiration.type, and activationRules.maximumActivationDuration all resolve before accepting the JSON as a valid PIM eligible role assignment request, the fields Entra ID PIM needs to schedule the eligibility grant and its activation constraints; it can't verify the referenced principalId or approvers group actually exist in your tenant, those checks happen only against the live Microsoft Graph API.
Always distinguish between scheduleInfo.expiration (how long the eligibility itself lasts) and activationRules.maximumActivationDuration (how long a single activated session lasts), conflating the two is a common misconfiguration that either leaves eligibility open far longer than intended or activation sessions shorter than actually needed for the work.
requireApproval with a real, responsive approvers group is what makes PIM's approval gate meaningful, an approver group that's slow or unresponsive to approve requests just pushes users toward requesting overly-long activation durations to avoid needing to re-request, undermining the just-in-time model.
Route onActivation notifications to a SOC or security-monitoring channel (as the example does with soc-team@contoso.com), not just to the requesting user, since a compromised account activating a privileged role is exactly the scenario this notification should surface to defenders quickly.
Was this tool helpful?
Disclaimer: This tool runs entirely in your browser. No data is sent to our servers. Always verify outputs before using them in production. AWS, Azure, and GCP are trademarks of their respective owners.