One of my challenges with every family release: is finding the undocumented 😀. Turning the Yokohama family release inside out, I came across "User Role Histories" [sys_user_role_history]. Not sure what to make of it, it looks nice though perhaps also double with something already present in the instance.
Let's document the undocumented and have a closer look at Yokohama's undocumented User Role Histories.
User Role Histories
When a new family release becomes available, I'm hunting for new System Properties, Flows/Subflows/Flow Actions, Tables, etcetera. New tables that popped up with the Yokohama family release concern User Role Histories.
The two "*sync_status" tables are interesting to have a look at, though the User Role Histories table appears to be the most interesting one.
Basically this new out-of-the-box table with data concerning when roles were assigned to users and when roles were removed from users. Interesting detail… the data is populated even with data from ancient history!
The exact how/what behind this I couldn't track down (yet). Though using Code Search I did come across these three (3) Sys Jobs [sys_job] that might have to do with this.
Good to know, there is a retention period set on User Record History records for "Removed On". A new Table Cleaner was added that has an "Age in seconds" set to that is the equivalent of 30 days. I'm not sure if this Table Cleaner is a good thing or not, or that you need to take this into consideration when doing new implementations or upgrading to the Yokohama release. Keeping this data feels useful, although… don't we already have an "Audit Roles" [sys_audit_role] table out-of-the-box?
Searching on, I did notice nine (9) new System Properties that seem to be related to this new functionality. These System Properties give the impression that the Sys Jobs (or something else?) is highly configurable. I've got some more investigation to do…
Audit Roles
"Don't we already have an Audit Roles table out-of-the-box" I mentioned above. A table which - after activation of System Property "glide.role_management.v2.audit_roles" - is populated with every user role change on the instance. There's also no Table Cleaner present for the "sys_audit_role" table, which means that this data will start to populate from the seconds you activate the System Property and stay in the instance indefinitely.
The only thing is, you need to activate the System Property. Out-of-the-box this is not the case, leaving a ton of customers without this valuable information!
Identity Security Audit
At first glance, User Record History and Audit Roles seem to overlap, did ServiceNow just add something new that is actually already available? Looking at that there is more involved, amongst others the nine (9) System Properties, I decided let's search further. Already having spent too many hours on this subject, I noticed that the User Roles Histories table is part of a plugin called "Identity Security Audit" [com.glide.security.audit].
A plugin that doesn’t ring a bell to me. What I do in such cases, is try to have a look if I can find the plugin and see what files it contains.
And now it even gets even more interesting! While I do want to wrap up this article… Oke leaving you with a cliffhanger, I guess a part 2.
Looking into the plugin files noticing several interesting files, like "User Trails", "Group Trails", "Role Trails", and "ACL Trails".
This plugin doesn't appear to be new by itself, I just didn't see it before and haven't noticed anyone publishing content on Identity Security Audit. The tables mentioned earlier in this article are new with the Yokohama release though!
---
That's it. Hope you like it. If any questions or remarks, let me know!
| C |
If this content helped you, I would appreciate it if you hit bookmark or mark it as helpful.
Interested in more Articles, Blogs, Videos, Podcasts, Share projects I shared/participated in? |
Kind regards,
Mark Roethof
Independent ServiceNow Consultant
10x ServiceNow MVP
---
