In the world of Identity Governance and Administration (IGA), “standard” is often just a starting point. Every organization has unique requirements for how they track and report on their users. However, these custom requirements can sometimes create unforeseen hurdles for automation.

Recently, we solved a complex offboarding challenge in One Identity Manager that required balancing a custom reporting structure with a seamless Microsoft 365 Out-of-Office (OOO) automation.

The Problem: The “Terminated” Location Black Hole

Our client required a specific custom change during the termination process: when an identity is offboarded, their Location property must immediately be updated to a container reflecting the year of termination (e.g., “Terminated 2025”).

This is excellent for HR audits and reporting, but it created a major issue for our automated OOO script. The OOO message needs to be localized, pulling a Helpdesk Phone Number and Helpdesk Email from the user’s specific site location.

The Conflict: 1. The termination process triggers and moves the user to the “Terminated 2025” location. 2. The OOO script fires, looking for helpdesk data on the current location. 3. Since “Terminated 2025” has no helpdesk metadata, the script is left with empty variables.

The Solution: A Resilient, State-Aware Architecture

To respect the client’s reporting needs without breaking the user experience, we engineered a three-tier solution.

1. Schema Extension: The “Last Known Good” State

We extended the One Identity Person table with a custom property: CCC_LastValidLocation.

During the termination workflow—and crucially, before the move to the “Terminated” container—we capture the user’s original UID_Loc and store it here. This preserves the geographical context of the user, making the automation “immune” to the subsequent location change.

2. The Orchestration Script & M365 Integration

We developed a custom script that acts as a bridge between the identity store and the cloud. Instead of using static templates, the script:

• Fetches the CCC_LastValidLocation.
• Retrieves the specific helpdesk metadata for that site.
• Dynamically builds the HTML body of the OOO message.
• Executes a PowerShell cmdlet (Set-OofMessage) to update the user’s OOF message in Microsoft 365.

3. The Fail-Safe: Default Fallback Logic

In a perfect world, every location object is fully populated. In the real world, data gaps happen. To ensure the script never sends a broken message or fails mid-execution, we implemented fallback logic.

If the script finds that the HelpdeskPhone or HelpdeskEmail fields are null on the location object, it automatically defaults to a Global Corporate Helpdesk contact. This ensures that the external correspondent always gets a valid point of contact, maintaining the professional image of the company regardless of data quality at the site level.

Why This Matters for Your IGA Strategy

This project highlights the difference between simply “installing” a tool and “architecting” a solution:

• Adaptability: we supported a custom business process (Location change) without compromising functionality.
• Technical Depth: We leveraged the One Identity Object Layer and PowerShell integration for end-to-end automation.
• Resilience: By adding fallback logic, we built a system that is “self-healing” even when source data is missing.

At the end of the day, IGA is about making sure the right people have the right access, and that when they leave, they leave with a professional, automated, and accurate “goodbye.”

Contact us for more information about your next IGA project!