We have implemented xMatters for our organization and have chosen to administer groups, group members via ServiceNow.
We have groups which have been granted the x_xma_xmatters.xmatters role. The group, group supervisor and members are successfully sync'ed; however, many of the users aren't getting a supervisor so escalation isn't working.
Should the Group Supervisor in xMatters automatically be added to the list of supervisors for a given user? e.g. if I am a member of both Support Group A and B. Support Group A has a group supervisor (Mickey Mouse) and Support Group B has a group supervisor (Minnie Mouse); upon exporting my user profile and checking the User Supervisor field, I should see the User ID for both Mickey and Minnie, should I not?
Comments
Please sign in to leave a comment.
What do you see here:
"On the xMatters Configuration > Data Sync configuration page, the Supervisor field displays the user that will be set as the supervisor of any users added to xMatters by the data sync."
I'll also mention that escalation does not require a user have a supervisor.
I wouldn't necessarily expect the default sync to make a Group Supervisor also the Person Supervisor for a user in a given group. Group Supervisors and Person Supervisors are different roles. I believe the default sync will make ServiceNow Supervisors > Person Supervisors in xMatters, and ServiceNow Group Super Managers > Group Supervisors.
Given what you've stated, if the person in the "manager" field on sys_user isn't an xMatters user, then there won't be a user supervisor value set, correct?
Hi Curtis,
That is entirely plausible. If the user has no manager as a person in ServiceNow it stands to reason that will also be the case in xMatters. The group supervisor and person supervisor can be different, especially if the user is part of several groups and the integration has to account for that somehow.
If you test that out and find something different then further discussion on the topic is likely warranted.
The more official answer based on the integration documentation:
https://support.xmatters.com/hc/en-us/articles/115004327803-ServiceNow-integration-version-5-1-
ServiceNow supervisors are synced to xMatters with the Person Supervisor role, if they don't already have it.
For a user's supervisors, the process is additive – when the data sync happens, if a user has a supervisor in xMatters that they don't have in ServiceNow, the xMatters supervisor remains in place (in addition to any supervisor included in the sync from ServiceNow).
ServiceNow group managers are synced to xMatters with the Group Supervisor role, if they don't already have it.
You can choose to sync group managers from ServiceNow even if they don't have the xMatters sync role (x_xma_xmatter.xmatters). To use this feature, select the Always Sync Group Managers option on the xMatters Configuration – Data Sync page.
If you want some default supervisor added for users like the sync user for example:
On the xMatters Configuration > Data Sync configuration page, the Supervisor field displays the user that will be set as the supervisor of any users added to xMatters by the data sync. The selected user MUST exist in ServiceNow and must have the "x_xma_xmatters.xmatters" role.
If the selected supervisor does not exist as a user in ServiceNow, or does not have the "x_xma_xmatters.xmatters" role, the user and group data sync will not complete properly.
While I'm sure this is nothing new, and it doesn't confirm exactly what you are saying about what table the integration refers to for user supervisors, the implied result is that these are different in Servicenow and we are mapping like to like during the sync process to xMatters.
Let me clarify, in ServiceNow we have the following
Bob - user, has xmatters role
Jane - Group Manager in S/N, has xmatters role
Bill - Bob's HR manager as shown on sys_user, does not have the xmatters role
Jane's Group - Bob is a member and Jane is Group Supervisor
Given the above, Bob is sync'ed as an xmatters user, is added to Jane's group; however, Bob doesn't have a supervisor.
Hi Curtis,
Based on the above example, if you had that toggle to always sync person supervisors turned on then Bill SHOULD sync to xMatters WITH the Person Supervisor role AND be added to Bob's Supervisors list.
IF that toggle is NOT on, then Bill MUST have the xMatters role AND be sync'ed to xMatters (ideally first) and then I would expect Bob to sync with Bill as his supervisor.
I would suggest trying this:
> Remove Bob's xMatters role or maybe remove him from the group temporarily.
> Add the xMatters role to Bill, forcing the sync to xMatters for him
> Add Bob back into the group OR give him the xMatters role again, forcing him to re-sync.
I would suspect at that point the supervisor should show as expected.
Cheers!
Hi Curtis,
Yes that was the option I was thinking of but that is very much labelled for Group Supervisors (which I would expect DOES work to set a group's supervisors properly) but wont' affect user supervisors. Ok... well we can set that out of the way at this point.
Coming back to my other suggestion, if you remove Bob and sync Bill first (should not matter what role he is given in xMatters, only that he has the xMatters role in ServiceNow and is brought over) then bring Bob in, I would expect Bill to become the supervisor for Bob as we can imagine.
Now the big question would become - how to automate all of that. If we come to this point, it would be time to consider either a customization or use the bulk upload to get all the managers in the sys_users table and move them to xMatters or find a way to refer to that table before bringing in any users/groups to make sure those supervisors are brought in first.
Let me know if this is where we're at so we can see about some options.
Yeah, agreed. I am now considering a business rule which would act on Insert/Update, check to see if the user in question's manager already has the xMatters role and if not, add it, thus making both new user and HR manager candidates for dynamic sync.
removal of the role is trickier as the hr manage will likely have many people which report to him/her so we can't remove the role just because one user is no longer participating.
Perhaps a scheduled job to create a collection of users reporting to Bill and if none have the xmatters role, then remove it from Bill.