SOD Approval Workflow Issue

[krunalkadam]

Issue: SOD Approval Workflow

Issue Description:

Currently, our workflow has two stages: manager and endpoint owner level. Our goal is to implement an improved access approval workflow that includes an additional level - Risk owner approval for entitlements with detected SOD violations. We have created a straightforward serial workflow with Risk owner approval for testing purposes, and the findings are detailed below.

Saviynt EIC Version Tested on:

23.5, 24.2

SOD Risk Configuration:

We have set up the following two risks in the SOD configuration:

1. Risk 1: Function 1 (Entitlement 1 of app1) and Function 2 (Entitlement 2 of app1) - Risk Owner 1
2. Risk 2: Function 3 (Entitlement 3 of app1) and Function 4 (Entitlement 4 of app1) - Risk Owner 2

Current Behavior:

When both SOD risks are violated in a single request, the request is sent to both risk owners for all entitlements simultaneously, with only 1 SOD violation visible after request submission.

Example:

Request raised: App1 -> Entitlement 1, Entitlement 2, Entitlement 3, Entitlement 4

Approval workflow:

Request pending for Entitlement 1 with: Risk Owner 1 and Risk Owner 2

Request pending for Entitlement 2 with: Risk Owner 1 and Risk Owner 2

Request pending for Entitlement 3 with: Risk Owner 1 and Risk Owner 2

Request pending for Entitlement 4 with: Risk Owner 1 and Risk Owner 2

Expected Behavior:

If both SOD risks are breached in a single request, the request should be divided into two parts sent to respective risk owners for each entitlement. Both SOD violations must be visible after request submission.

Example:

Request raised: App1 -> Entitlement 1, Entitlement 2, Entitlement 3, Entitlement 4

Approval workflow:

Request pending for Entitlement 1 with: Risk Owner 1

Request pending for Entitlement 2 with: Risk Owner 1

Request pending for Entitlement 3 with: Risk Owner 2

Request pending for Entitlement 4 with: Risk Owner 2

Configured Approval workflow:

The following is the approval workflow we have created:

Alternate Approach:

We have also examined an alternative method involving the creation of a custom assignment task in a parallel workflow to designate approval responsibilities to risk owners. In this scenario also, all SOD-violated groups are sent to all risk owners for their approval.

Example:

Request raised: App1 -> Entitlement 1, Entitlement 2, Entitlement 3, Entitlement 4

Approval workflow:

Request pending for Entitlement 1 with: Risk Owner 1 and Risk Owner 2

Request pending for Entitlement 2 with: Risk Owner 1 and Risk Owner 2

Request pending for Entitlement 3 with: Risk Owner 1 and Risk Owner 2

Request pending for Entitlement 4 with: Risk Owner 1 and Risk Owner 2

Questions:

1. Is there any configuration we are missing in Saviynt EIC?
2. Is the observed behavior expected of Saviynt?
3. Is there any open issue with Saviynt on this?
4. How to resolve to get the expected outcome from the approval workflow?

[Dhruv_S]

Hi @krunalkadam 

Thanks for reaching out to Forums. We are checking this. We will keep you posted.

Regards,

Dhruv Sharma

[Dhruv_S]

Hi @krunalkadam 

I tried to replicate the scenario. Please find the observations.

Issue 1. Entire Request with all the entitlements is going to both the Risk owners.

It is an expected behavior as per the current product behavior with the SOD owner block.

Issue 2: Both SOD violations must be visible after request submission.

It seems to be a bug when the request is raised with Risk1, Risk2, both the Risk owners sees the request is showing only Risk1 as a violating entitlement.  I have opened a ticket (#INC-2021772). I have tried to replicate this with latest version NEO experience. I will analyze it further and associate a bug once confirmed.

Regards,

Dhruv Sharma

[Dhruv_S]

Hi @krunalkadam 

This is to inform you that the issue of SOD risks to be presented to respective risk owners is planned to be fixed in 24.7 as per SOD-2855

Regards,

Dhruv Sharma