Roles not assigning unless via "Apply Changes"

I am not seeing roles with assignment criteria being an entitlement get assigned to users UNLESS I click “Apply Changes” on the roles page. Every time I click “Apply Changes” I see the roles get assigned, but otherwise I do not. Other methods I have tried include processing a single identity, refreshing all identities in an identity profile, and running target source aggregations.

For what it’s worth, we are trying to “recursively” set access by having role C contain entitlement B, which role B uses as the assignment criteria. Unsure if this specifically is the culprit.

As a sort of workaround, is there a way to automate the functionality behind clicking “Apply Changes”? I was under the impression that “Apply Changes” on the Roles page was functionally the same as refreshing all identities.

I have been speaking with my SailPoint expert services representative and it seems like the only solution to automate “Apply Changes” is by using the /beta/identities/process endpoint (start-identity-processing | SailPoint Developer Community).

The actual endpoint that “Apply Changes” calls is /ears/roles/roles/refresh?optimized=true but it is impossible to call this API using a PAT. The only way to call this API is with the session token retrieved from the url.

My feedback to SailPoint: create a lighter weight refresh roles API that I can call to apply the role changes without having to call the more resource intensive /beta/start-identity-processing/.

Does the role get assigned when the identity is assigned that entitlement for the first time?

Hey Kirby,

Since I am essentially creating nested SailPoint roles, the behavior I see is as follows:

SP Role A added to identity as well as the entitlement contained in SP Role A (called Entitlement B).

Upon next “Apply Changes” call, SP Role B is added to identity (since assignment criteria requires having Entitlement B) and Entitlement C is added.

Upon next “Apply Changes” call, SP Role C is added and Entitlement D, etc.

I hope this clarifies the situation.

Hi @dominick-miller,

Yes, I understand this is what you’re experiencing when you set up new roles. This is working as expected.

I’m going to assume you get SP Role A because Identity Attribute Z is equal to a certain value.

Once you’ve configured roles A, B, and C, what happens when an identity sees their Identity Attribute Z meet the criteria of SP Role A?

  • They get Role A, B, and C?
  • They get Role A, and you need to refresh them to get them into B and C?

Hi @kirby_fitch,

To clarify: SP Role A assignment is being driven by entitlement ownership, much like SP Roles B, C, D, etc.

To answer your underlying question: multiple “Apply Changes” are needed to get them into Roles B and C. The structure is provided above.

Actually, I have noticed different behavior between “Apply Changes” and the nightly SailPoint refresh. Upon nightly SP refresh, it appears that multiple Roles are added per SP refresh. During “Apply Changes” role refreshes, one role is added per refresh.

I know SailPoint does not encourage automation of the /beta/identities/process API, but that seems to be the only endpoint I can use to automate this role assignment.