Certifications: Filtering Birthright Access & Provisioning Failure

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

Hey everyone,

We are running a certification campaign in SailPoint Identity Security Cloud (ISC) and we’ve hit a major problem affecting both reviewer experience and provisioning success.

Our goal is to certify only ad-hoc access profiles (APs) that were manually requested.

Our Setup:

Roles grant Entitlements (This is our Birthright access).

Access Profiles (APs) grant the same Entitlements (This is our ad-hoc access).

The Two Major Problems:

Problem 1: Reviewer Overload (Filtering)
Our certification is showing ALL access, including the entitlements granted by the birthright Roles, even though we only want to review the ad-hoc APs.

Reviewers are presented with a huge amount of access they don’t need to review (it’s covered by a permanent Role/Birthright).

How do we configure the certification campaign to only display Access Profiles that are not granted by a Role?

Problem 2: Provisioning Failure (Revocation Conflict)
When a reviewer marks one of the overlapping ad-hoc Access Profiles for removal:

The provisioning task fails because the underlying Entitlement is still actively tied to the user’s Role. ISC tries to remove the Entitlement entirely, which is blocked by the active Role assignment.

What is the best practice in ISC to solve this provisioning logic?

Is there a standard setting we can use to tell the system: “If this entitlement is also granted by a Role, just remove the Access Profile assignment and skip the entitlement removal push?”

This issue is creating noise for reviewers and technical failures for remediation. Any guidance on how to properly separate and manage birthright vs. requested access in ISC certifications would be extremely helpful!

1 Like
2

@trettkowski For problem 1, have you tried Search based campaign → Access item certification with filtering AP’s you want to certify by running a query?

For problem 2, I’m not sure if something like that would be possible by design of the SP. You will might need to redefine the birthright roles’ accesses manually. I guess someone more experienced can answer this more precisely.

3

@trettkowski You can explore the object tagging functionality where you can tag all the in scope Access profiles and later use it in your query to create the campaign as required.