HR Triggers - Auto Provisioning Fails for Change and Lock User Request

[former_member319356]

Dear All,

We are implementing HR Triggers in our systems for Terminations only, the request type is "Change and Lock".

We are getting a provisioning error if the user doesn't exist in the target systems.

If we check the option "Create user if does not exist - For Change User Action", underneath SPRO > Maintain Global Provisioning, it works, but a new shell user is created and then locked.

We don't want to create a lot of Shell users for nothing, we have hundreds factory emplyees that will never have SAP access for example. But whenever HR does a termination an ARQ is raised, independing if the employee have SAP access or not. We just want to ignore the error if the user doesn't exist and close the request, but today it goes to the escape path "Auto provisioning error" and waits for approval.

Please let me know if you have any suggestions.

Thanks

Jeferson

[former_member319356]

Hi Alessandro, here is the log. We are working with ABAP in a workaround, we are making a custom program to automatically approve these requests with a daily Job, we are looking if it's possible to check if the users exists in the target system and then reject individual line items corresponding to the systems were he doesn't exist

.

Thank you.

[alessandr0]

Dear Jeferson,

the request shouldn't fail. Please share your audit and provisioning log.

Regards,

Alessandro

[former_member319356]

Hi Prasant and Alessandro, thanks for your response.

The problem is we are using HR Triggers to lock users in CUA Production, Dev, Test and Sandbox systems, and also HCM Prod/Dev/Test which are not connected to CUA. If the user doesn't exist in just one of these systems the request fails, i don't see a way to remove just one of the systems in the ARQ if the user doesn't exist, any ideas?

Thanks

Jeferson

[alessandr0]

Dear Jeferson,

just implement another logic into your BRF+ decision table that checks if the user exists in the system. If not, then skip the request and don't initiate a change & lock request. To check if a user exists, you can for example utilize a DB Lookup function to check table GRACUSER, or GRACUSERCONN for a particular system.

Hope that helps.

Regards, Alessandro

[former_member193066]

Unwanted request is getting raised because of decision table, PLease change your logic to more relevant so unwanted request cannot be raised.

You can enable SLg1 logs and view more details and specify parameter to determine actions.

Regards,

Prasant