User records not updating through Scheduled LDAP Import

[harun_isakovic]

Hello Community,

I'm having an issue with my Scheduled LDAP Import, but I cannot figure out why its not updating all users, it updates majority but then there is some that it does not for whatever reason. I was monitoring this specific user (we will name him David W.) and his company is not updating on his LDAP record the company is "A" but on SN its "B".

I can see the data gets loaded into the staging table and I find David W. record there with the latest data from LDAP but for some reason this data does not get updated in his user record in SN.
If I go into the Import Log table and find the error record for this user all that says is "Error during insert of sys_user (David W.)

In the Scheduled Import set the "Run as" was empty even when it was working but, now Ive put a user in that field that has the "import_admin" role but it still does not work.

Coalesce on the transform map is set to employee_number, but this field is hidden by an ACL that restricts view only to security_admin role. 

There is also a field on the user record "Refreshed from LDAP" which tells me when this user was last refreshed and its pretty much same date for 2 weeks now.

Would appreciate some help with this!
Thanks in advance.

[Allen Andreas]

Hi,

Since the error is saying "Error during insert of sys_user..." then it's attempting to insert the user. Which...it shouldn't because you're coalescing on the employee number field, right? I believe the problem from this is due to the ACL restricting vision to it. So during the transform it can't read the employee number on any sys_user record...so initially it thinks well hey...I have an employee number here (in the staging table) and I don't see a match for it on sys_user (because it's blocked by ACL) and so I'll insert it...

When it tries to insert...it hits a wall because you can't have duplicates and fails.

For testing purposes, please make the restrictive ACL regarding "read" for the employee number...inactive. See if it works. I suspect it will.

Please mark reply as Helpful/Correct, if applicable. Thanks!

[harun_isakovic]

Hi I will give it a try and provide feedback.

Thanks!

[harun_isakovic]

Hi Allen,

This seems to have not worked either. Still there is users that did not update and I went to the import set logs and saw that the error for David W is still same. But also went to the Import set for that specific data load and found that the Target Record for David W is empty. Why is this?

[Allen Andreas]

Hi,

You'd need to double-check all "read" ACLs for the sys_user table to see what may be blocking vision to the employee number field. Only you would know that as it's your instance. So you'd want to check table and field ACLs.

As far as the import set target record being empty that's because it doesn't know which record to associate it to. It's thinking it needs to create a new record, but when it tries to and uses the same employee number from the staging table...your coalesce rule on it hits and creates most likely a duplicate error and it aborts creating it.

You'll only see target sys_ids when it successfully lands where it needs to go.

To me, you still have some ACL(s) preventing this from moving forward.

Check your system log as well after this attempt is made as I imagine a duplicate error or something to that effect should show there.

Please mark reply as Helpful/Correct, if applicable. Thanks!