Time-Based Identity Refresh enables precise scheduling of identity processing using the Next Processing Date attribute. This approach ensures critical events, like onboarding and offboarding, occur at the exact required time. In this session, we’ll explore how it works, its benefits, and how to configure it for seamless identity lifecycle management.
The value for nextProcessingDate must be in ISO 8601 format, but it does not need to be in UTC. You can include a local time with a time zone offset (e.g., CST), and SailPoint will automatically convert it to UTC during processing.
So both of these are valid and supported:
2025-04-01T06:00:00-05:00 → 6:00 AM CST (UTC-5)
2025-04-01T11:00:00Z → same moment expressed in UTC
What’s not valid is combining both an offset and the Z suffix, like this:
2025-04-01T06:00:00-05:00Z
This is incorrect because it mixes two different time zone indicators (offset + Zulu/UTC), which creates ambiguity.
Hello,
I see that when mapping the nextProcessing attribute, you set your example source to “Workday Fake” and the attribute to “description”. What practical purpose does the “description” attribute server, and how does it help create a date attribute?
both the source and the attribute for the example are just a place holder. The only requirement is that they resolve to a value so that the transform can get triggered. The value doesn’t end up feeding into the transform - so it can be anything. Commonly we use values like FILENUMBER from workday since its always going to be populated.