We have a ServiceNow Governance Connector set up which is working fine with Create Account. However, for the manager field in ServiceNow we are sending manager’s employee number (is an identity attribute) from SailPoint that is used for finding the record corresponding to manager in SNow sys_user table and referenced for the user record.
What we like to do is to add this to attribute sync so that whenever a manager is changed for any employee (either Mover case or old Manager is no longer part of the company), but because the manager field read back from SNow is the display name of the manager which will not match the manager’s employee number identity attribute, we are worried that this will go into an infinite loop of updating the field.
Has anyone ever have faced a similar situation, and how have your resolved it?
Haven’t used this connector personally, but here’s what I’m thinking:
The connector should handle your described scenario gracefully, without infinite loop.
Justification:
AD expiresOn has had a similar issue (e.g. what’s written out is not what’s comes back from aggregation).
The connector needs to handle this situation. If it doesn’t, I see it as a bug.
This is not happening in ServiceNow connector and I was not expecting it to happen. Case of AD expiresOn might be different as the conversion would be a predefined one and SailPoint added a fix for this specific source and attribute. However, in our case SailPoint would not know which identity attribute is used (each tenant may use their own) and what is the format of value returned from SNow. I don’t think there is a way add an OOTB feature to handle this.
Are you saying that you’re sending ServiceNow the manager’s employee number from SailPoint to the sys_user.manager field? I would assume since this is a reference field on the ServiceNow side it correctly resolves since that employee number exists on the manager’s record. Just want to make sure I understand this correctly.
(we don’t create ServiceNow users from SailPoint in our environment so I’m more curious than anything)
It would probably require that you store ServiceNow user sys_ids as an identity attribute, but this way, the manager account attribute will always be the sys_id instead of the display name. IDK, worth a shot maybe?
We are sending the manager’s employee number to SNow and as a part of what happens on SNow side while data is transferred from ISC Governance app staging table to sys_user table, the employee number is used for finding the manager’s record in sys_user table and correct value is added under manager column for the new user. This is working fine.
This may not work as this will make the sys_id to be displayed for manager under the account in SailPoint which will not be a match to identity attribute “managerEN”
We will still have to convert this sys_id to employee number.
When a manager changes, same is captured by updating the identity attribute named “managersEN” which is a unique number coming from HR
Oh wait, I think I’m seeing where I’m going wrong here, because you’d need to store the manager’s sys_id on the employee’s identity… yeah, that would probably be more complicated
Create a custom field on the sys_user table (which I’m sure your ServiceNow team will love) for managerEN, then create a ServiceNow business rule on the sys_user table that fires on insert/update (specifically when the managerEN field changes) then perform a GlideRecord lookup on sys_user for that employee number, then populate it in the manager field.
In our SNOW implementation we synch the manager name to what is referred to as the manager account field in SailPoint ISC. We have a custom identity attribute that has the name of the manager and we synch that attribute versus the employee number. works great.
