Time-based identity refresh

Content Video Library
,
1

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)

image
image1920×1007 68.5 KB

2

Good use case explanation and solution

1 Like
3

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

4

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.
1 Like