sys_user table sys_id synchronization with Azure User object id
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎01-21-2022 08:46 AM
We are trying to have our Azure portal drive all the users, groups and group memberships on ServiceNow via the Azure ServiceNow enterprise application.
For simplicity, we want to synchronize objectid on Azure users with sys_id on ServiceNow users (so that any applications talking to either Azure or ServiceNow can uniquely identify the same user when using the same user record key).
What we found is that the Azure ServiceNow enterprise application allows the mapping on the portal interface (in Provisioning/Attribute Mapping section, objectId -> sys_id), the ServiceNow instance who creates new users would ignore that mapping and assign its own sys_id (so they will be different).
If we map objectId to other fields that support random values (such as street, etc), it works correctly. It just does not work with the sys_id field.
To be clear, we are talking about having the two sides in sync when CREATING new user records. There's no attempt to CHANGE the existing sys_id values on ServiceNow side.
Could someone shed some light on this behavior of ServiceNow? Is there something special we have to do on the ServiceNow instance side to make that happen? - Thank you in advance.
- Labels:
-
Connect

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎01-21-2022 02:12 PM
Thanks
I agree that it seems fraught with issues down the line, but it seemed odd that it's even offered as a mapping target if it isn't best practice or doesn't work, so we were wondering if there's something we missed there, or if the tool is off with that field!
Kristin

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎01-21-2022 02:21 PM
Hi,
Please see my reply above.
I think you're misinterpreting what is being presented in Azure as far as mapping selections as it's not as intuitive as you think or expect. I believe it's just simply querying the database for that table and retrieving all fields. It doesn't "technically" mean it's eligible to be used and each field has it's own downstream security/processing, etc. within your instance.
Thanks!
Please mark reply as Helpful, if applicable. Thanks!
Please consider marking my reply as Helpful and/or Accept Solution, if applicable. Thanks!

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎01-21-2022 02:53 PM
Thanks! I think you and I were typing at the same time as each other...I hadn't seen your second reply when I sent mine!
I agree with what you're saying and I think we'll decide it's not worth the customization or future risk to manipulate the sys_id field. Despite the fact that some of the mapped fields do populate "one for one" so to speak, I don't believe the objectid/sysid is intended to behave the same way. I think it's the "downstream" processing you reference that handles what happens with the "mapping".
Take care and thanks for the feedback!
Kristin

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎01-24-2022 06:34 AM
Hi,
You're absolutely welcome!
Thanks and take care! 🙂
Please consider marking my reply as Helpful and/or Accept Solution, if applicable. Thanks!