Time-based identity refresh

Description

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.

Determine NextProcessingDate Transform:
Determine NextProcessingDate.json (9.1 KB)

Determine LifecycleState Transform:
Determine LifeCycleState.json (14.3 KB)

Sample Input:
startDate: 2025-04-01T06:00:00-05:00.
endDate: 2026-12-15T15:00:00-05:00.

Presentation Deck:
SailPoint_Time-based identity processing_ISC Stage 1_DevDays 5.22.25.pptx (3.1 MB)

3 Likes

Good use case explanation and solution

1 Like

Great presentation Natalia,

A quick question though. Is the assumed ISO8601 in UTC? or is that a CST value with an offset

example.

2025-04-01T06:00:00 (UTC)? or 2025-04-01T06:00:00 (CST).

Also, what happens if they include Z at the end of the string
2025-0401T06:00:00-05:00:00Z

Hi Bradley,

Great question — thanks for asking!

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:

  • :white_check_mark:2025-04-01T06:00:00-05:00 → 6:00 AM CST (UTC-5)
  • :white_check_mark: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:

  • :cross_mark: 2025-04-01T06:00:00-05:00Z
    This is incorrect because it mixes two different time zone indicators (offset + Zulu/UTC), which creates ambiguity.
2 Likes

How do you differentiate the refresh for Lifecycle management vs other things(attribute refresh, attribute sync, Role assignment etc) in this?

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.