Automating International Travel Access Notifications with Entra Entitlement Management
Problem
Manual, easily-forgotten process for granting and removing temporary access during international travel
Outcome
Self-service access requests with automated, reliable notifications — removing dependency on a busy service desk remembering to act
The Problem
The organization used Conditional Access to block sign-ins from outside expected locations. It’s a strong security control, but it created a real headache for employees traveling internationally. Travelers needed a temporary exception granted before they left and removed after they got back, and that process was entirely manual, resting on service desk agents remembering to act on each request. It broke down under real ticket volume. Employees sometimes landed at their destination locked out of company systems because the exception hadn’t been granted in time. Other times, access lingered for weeks after a trip ended because nobody caught the removal.
The Approach
We replaced the manual request process with self-service access packages through Microsoft Entra Entitlement Management, so travelers request their own “traveling” access directly through MyAccess. A second access package, requiring executive approval, handles travel to a defined list of higher-risk countries.
To make sure approved requests actually got acted on, we built a PowerShell runbook running on an Azure Automation Account under a system-assigned managed identity. It monitors approved requests and automatically notifies the service desk with the traveler’s destinations and dates, so exceptions get applied without anyone needing to remember to check a queue.
The runbook handles both new travel requests and trip extensions as separate events, since a trip running long needs its own notification without duplicating or disrupting the original one. It also logs every request it’s already processed to a CSV file in Azure Blob Storage, checked on each run, so a scheduled job never emails the service desk twice about the same request.
For authentication, we used Microsoft Graph application permissions scoped directly to the managed identity. No interactive login, no stored credentials. We also paired that with an Exchange Online application access policy restricting the automation to send mail only from one specific shared mailbox, which closes off the broader risk of an app-only mail permission being able to send as any mailbox in the tenant. There’s also a separate failure-alert path: if a notification ever fails to send, someone gets notified internally so it doesn’t go unnoticed.
Technical Highlights
The runbook correctly distinguishes “approved and active” access from “approved but not yet started” access (both are valid states worth notifying on), while filtering out unrelated system states such as denied requests that could otherwise trigger false notifications.
We ran into a Microsoft Graph filtering limitation and worked around it by querying multiple access packages independently instead of relying on a combined filter that Graph didn’t support.
The Outcome
This removed the service desk as a manual, error-prone bottleneck in the travel access process. Employees can now request their own access ahead of time instead of hoping a ticket gets processed quickly enough. Because the notifications are automated, the gap that used to let access get granted late or left active long after a trip ended is closed.