requiresPeriodicRefresh - strangely undocumented?

Identity Security Cloud (ISC) ISC Discussion and Questions
,
1

We need to talk about requiresPeriodicRefresh.

This optional attribute is present on a number of transform primitives, but the full extent of the documentation for it consists of one sentence:

This true or false value indicates whether the transform logic should be reevaluated every evening as part of the identity refresh process.

This has been brought up previously, but didn’t get a response from anyone at SailPoint, only well-intentioned guesses from other customers/partners.

It would be great if this could be properly explained/clarified by an actual SailPoint employee who can speak authoritatively on the subject: how does this actually work? Additionally:

  • What is the default for requiresPeriodicRefresh, true or false?
  • How are true and false cases each handled on unscheduled refreshes that I manually trigger, or on refreshes triggered by nextProcessing?
2 Likes
2

Hey @sup3rmark,

After talking with a few people, here is what I have for you. I will update the documentation with this information as well.

The default value is false.

The flag is set to true on Transforms and Rules to force the 8am/8pm scan/refresh of an identity. This is to cater for the case where no other event triggers an identity refresh i.e. a catch all.

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 (Think provisioning/aggregation/nightly refresh), all attributes are re-evaluated.

Manual and time based via nextProcessing shouldn’t care about requiredPeriodicRefresh. They will both refresh the identity, regardless of the requiresPeriodicRefresh being true/false.

2 Likes
3

An important question here as well is how this works with nested transforms, considering both cases of nesting transforms through reference transforms and nesting transforms by directly defining the child transforms.

And taking this into account, why would this attribute only be documented on some transform types?

1 Like
4

This was designed specifically for those cases where you are evaluating against now and you want it to get evaluated daily and not only when account attribute change is detected(change in account attributes triggers identity refresh).
e.g. you have transform calculating LCS using termination date coming from workday where today > termination date gives inactive LCS.

termination date: 15th March 2025
HR enters termination date before 15th March, assume it’s done on 10th March.

If you are not evaluating daily in refresh job(default case of false) your transform calculation will run when there is change detected from workday , which will be on 10th March and LCS would be active as part of that refresh because 10th March is not past 15th March.

Any day after 10th March, scheduled refresh job would not pick up this attribute for refresh so it would stay in active LCS even after 15th March.

If that flag is true then transform logic is evaluated daily as part of refresh job so LCS is changed to inactive on termination date or after that.

IdentityAttribute rule type also has this tag which is

<Attributes>

    <Map>

        <entry key="requiresPeriodicRefresh" value="true"/>

    </Map>

</Attributes>

and it functions similarly.

default false was chosen to keep refresh job efficient and faster as not all identity attributes need re-calculation daily, only those which are time sensitive needs this re-calculation.

1 Like
5

I’ve updated my response here based upon internal responses I’ve received.

2 Likes
6

Thank you @chirag_patel for your reply, but your reply does not address the point I am making regarding nesting.

My point is regarding nesting.
To be more specific, suppose I have an identity profile mapping pointing to transform A (for example a lookup transform), and this transform A has child transforms B and C. Suppose that transform B is just an account attribute, but C is a date based transform comparing to the current time. Should the flag only be turned as true on transform A, or also on transform C? What will even happen if we only have this flag on transform C?

I have a strong suspicion for what the answer can be, but this technically depends on they way SailPoint has implemented transforms, (intermediate) caching, and inheritance of this property for nested transforms in the backend.

So can you help here @tyler_mairose by making sure that the documentation addresses this properly as well?

1 Like
7

The top level transform is the only one that needs the flag. This will trigger lower level transform references to re-calculate.

Transform A with the flag calling Reference Transforms without the flag.

2 Likes