requiresPeriodicRefresh - A New Discovery

[j_place (Jeremy Place)]

Ok, I’m not sure whether this is a new discovery, but it is to me.

You know how we’re all a bit puzzled about the requiresPeriodicRefresh Transform attribute?

No, I’m not talking about where to put it; we should all know by now that it goes in {attributes}, whatever the documentation says.

More about when to use it and when it runs.

Anyhow, I ran across the Identity Profile attribute hasTimeBasedAttr and it got me thinking.

The API docs say:

Indicates the value of requiresPeriodicRefresh attribute for the identity profile.

And, guess what; it gets set to true if any transforms used in the Identity Profile have requiresPeriodicRefresh=true. Remove the time based transforms and it gets set to false.

I suspect then, that, if any transforms have it set, it will trigger an Identity Refresh and all will get refreshed.

TBH, I haven’t done extensive investigations, these are just initial observations, and I probably won’t dig deeper, but thought I would share with the community.

[trettkowski (Tyler Rettkowski)]

So if you’re understanding is true, then there’s no way to choose what transforms are evaluated on the nightly sync? Basically if it sees requiresPeriodicRefresh anywhere, it will process all identity attributes on that profile at the nightly sync? That would align why I was seeing nested transforms that had requiresPeriodicRefresh also work.

To be honest, I don’t understand why this isn’t a default… maybe to save SailPoint compute resources?

[j_place (Jeremy Place)]

That’s my suspicion, yes, and your post was one of the ones that got me thinking. I suspect it is the equivalent of a manual Identity refresh. The test would be to have one attribute with requiresPeriodicRefresh as true and another as false and see whether the second gets refreshed.

[David_Norris (Terry Yau)]

This got me thinking…always remember what the backend is / was… which never had per-attribute refresh.

[trettkowski (Tyler Rettkowski)]

I recently connected with SailPoint Professional Services to get some clarity on this, and multiple Solutions Architects confirmed that the 8 PM refresh is evaluated strictly on a per-attribute basis.

This debunks the theory that enabling requiresPeriodicRefresh on a single attribute triggers a blanket refresh across all attributes during the evening sync. Only the specific transforms with the flag enabled will be evaluated.

Because of this, PS strongly advised against setting this flag on transforms that do not rely on time-based changes, purely for performance reasons. While it might not matter for smaller organizations, the performance impact is highly noticeable in environments with a large identity attribute footprint (my current client has over 70, for example).

I did specifically ask for official documentation to back this up. While there doesn’t appear to be any public-facing documents available right now, the consensus among the SAs makes this the most definitive answer we have on this somewhat “unknown” feature.

[Peddapolu (Venkateswar Rao Peddapolu)]

@trettkowski

requiresPeriodicRefresh

Hi WADR @j_place requiresPeriodicRefreshThis flag is an enabled date comparison between the start date and end date. When the data is null, the user will need to reevaluate it in prehire scenarios. This includes which indicates whether this transform logic should be reevaluated every evening as part of the identity refresh process.

Thanks,

PVR.

[j_place (Jeremy Place)]

Thanks @trettkowski

Thing is, that’s not what I’m seeing. Apologies for the delay in responding, I wanted to run some scenarios which, obvs, I can only run daily.

In my testing, I have 2 transforms:

{
    "id": "629caeb5-cc3c-4fe9-a26a-7ef3155b5ed7",
    "name": "JP - Static 1",
    "type": "static",
    "attributes": {
        "today": {
            "attributes": {
                "expression": "now"
            },
            "type": "dateMath",
            "name": "Current Date Transform"
        },
        "value": "$today",
        "requiresPeriodicRefresh": true
    },
    "internal": false
}

{
    "id": "c045577e-eb4c-4203-abdd-5a38c2daf418",
    "name": "JP - Static 2",
    "type": "static",
    "attributes": {
        "today": {
            "attributes": {
                "expression": "now"
            },
            "type": "dateMath",
            "name": "Current Date Transform"
        },
        "value": "$today",
        "requiresPeriodicRefresh": false
    },
    "internal": false
}

assigned to 2 Identity attributes:

and ISC consistently updates both attribute values:

[trettkowski (Tyler Rettkowski)]

Thanks for the info @j_place

Just to confirm, the 02:12:28 time provided there is supposed to be when the 8PM refresh occurred? I would expect everything to be evaluated on the 8AM, but if that’s the 8PM then I’m afraid I need to have a discussion (again) with the Solution Architects.

[j_place (Jeremy Place)]

Hi @trettkowski Yes, that’s the 20:00 refresh, my tenant is in the default Chicago TZ.

From Processing Identity Data - SailPoint Identity Services

Also from requiresPeriodicRefresh - strangely undocumented? - #2 by tyler_mairose

The requiresPeriodicRefresh option is there to force us to include the Identities with this configured on their IdentityProfiles into the 8pm refresh. Any time an Identity is refreshed […], all attributes are re-evaluated.

[trettkowski (Tyler Rettkowski)]

Thanks for the info! I’ll discuss with Professional Services and come back with my findings.

I think your test is pretty irrefutable, so I’ll have to see what they say. Maybe there’s some other reason why it’s getting evaluated.