Manager not being set even if owner field is populated

[alex1]

Hi,

We are currently mapping the manager in AD to the owner field in Saviynt with a preprocessor that looks like this:

"update NEWUSERDATA SET OWNER = (select CU.USERNAME from CURRENTUSERS CU where CU.CUSTOMPROPERTY36 = NEWUSERDATA.OWNER)"

Basically, we get the username from the user in Saviynt that has the DN value from AD set to customproperty36 (where we store the DN of all users). This works as expected and the owner is set correctly in the import. However, even when the job is completed successfully, the manager field remains blank. So basically, it looks like users have no manager even though that the owner field is set correctly to the username that we want. The username also exists in Saviynt (since the preprocessing works). 

In the logs, we can see that everything is mapped correctly in the users, and that a "managersql" task is running. Which looks like this:

Not sure if it means anything, but it looks like it tries to do something. No other messages related to this can be seen in the logs.

Summary:
Owner is set correctly from import, the set owner exists in Saviynt, however, the manager field remains blank. We have tried running the job multiple times and restarting the application, but no luck so far. Any help would be appreciated. 

[rushikeshvartak]

"update NEWUSERDATA SET OWNER = (select CU.USERNAME from CURRENTUSERS CU where CU.CUSTOMPROPERTY36 = NEWUSERDATA.OWNER)"

[alex1]

Thanks, I missed the parenthesis when pasting it here, but it is there. If it wasn't the owner wouldn't be set, so this has nothing to do with the query, since it returns the correct username for all users in the owner field, it is just manager that is not being set. 

[rushikeshvartak]

UPDATE NEWUSERDATA NU
INNER JOIN CURRENTUSERS CU ON CU.CUSTOMPROPERTY36 = NU.OWNER
SET NU.OWNER = CU.USERNAME;

[alex1]

Thanks again. What would that do? Looks like you are setting the owner, which is already working. We are able to set owner, but the manager field remains blank.

So the query above that we are using has no issues because the username of the person is in the owner field, but it doesn't get added to the manager field.

[rushikeshvartak]

UPDATE NEWUSERDATA NU
INNER JOIN CURRENTUSERS CU ON CU.CUSTOMPROPERTY36 = NU.OWNER
SET NU.MANAGER= CU.USERKEY;

[alex1]

Thanks again, from our understanding, we shouldn't have to set manager specifically, it should be enough to update owner. This works with our other imports, so its only this one that has this behavior. So we don't want to update manager specifically, instead we want to update owner and let the manager field be populated automatically.

[alex1]

This is the owner field: managerUsername exists in the tenant and is the username for another user. 

However, this is the manager field for the same user that has the managerUsername in the owner field after the import

[alex1 · Accepted solution]

Managed to solve it ourselves:

Basically, we had the same query, but in the user import we had defined the manager import such as:[USERNAME::sAMAccountName#String,OWNER::manager#String]

This made the preprocessing work, but it didnt set the manager field correctly. Instead we changed the row above to:

[USERNAME::sAMAccountName#String,CUSTOMPROPERTY60::manager#String]

and the preprocessing to:

"update NEWUSERDATA SET OWNER = (select CU.USERNAME from CURRENTUSERS CU where CU.CUSTOMPROPERTY36 = NEWUSERDATA.CUSTOMPROPERTY60)"

In the owner field, we see no difference, however, manager is now set correctly as expected. Basically, it might be a problem to set the OWNER in the user import and in the preprocessing, but if should work with any attribute other than owner. 🙂