cancel
Showing results for 
Search instead for 
Did you mean: 
Read only

Access Request for Multiple Users Always Hits Escape Path

Former Member
0 Kudos
406

Hello everyone,

My multi-user Access Requests seem to always hit the Escape Path after all approvals are processed. This is happening after the final approval and before provisioning. From the Escape Path I need to approve once again, and then the provisioning takes place without issue.

Does anyone have a note that they have used to address this?

System: GRC 10.1 SP18

Thanks,

Ken

Accepted Solutions (0)

Answers (2)

Answers (2)

japneet_singh2
Active Participant

Hi Ken,

Kindly implement the note 2636291 to resolve the issue .

Thanks
Japneet Singh

Former Member
0 Kudos

Hi Ben,

I am guessing you might have set up escape path for provisioning failures,can you share audit log screenshot for the multi access request.

Thanks

Ramesh

Former Member
0 Kudos

Sorry Ken.

Former Member
0 Kudos

Hi Ramesh,

After inspecting the audit logs of some of my multi-user requests that experience this issue, I have noticed a common denominator - they all include a user who has an "Alias" configured in SU01. In the audit log, just before the escape route is applied, I see the following notification:

"The alias "_____" already exists in (system)".

I believe this to be the root cause. Do you have any insights into "alias" in SU01 causing auto-provisioning issues?

Note: This particular Alias is unique in the system, and no other account has the same Alias. I am thinking that we should remove all Aliases because they are causing the issue. I saw an older post that Alessandro tried to help with, but there was no solution reported and the thread died.

https://archive.sap.com/discussions/thread/3730888

-Ken

Former Member
0 Kudos

Ken,

What's your EUP setting on the Alias?Do you use any logic to build the alias?

Thanks

Ramesh

Former Member
0 Kudos

EUP for Alia is:

Mandatory = No

Editable = Blank (no value)

Visible = No

No logic related to Alias in any config.

I'm going to try the note that Japneet Singh mentioned below, as it describes my scenario.

Thanks, Ramesh.