We recently made a change to the default name given to the initial shift in each new group that you create in xMatters. Quite a few customers felt that "24x7" - the original default name - was confusing. It wasn't clear if it was the name of the shift or a description of its time frame, and became even more confusing if the shift was set to a different duration.
In response to this feedback, we updated the group creation process in xMatters to call the default shift, well, "Default Shift". But while this made many customers quite happy, it also had a bit of a side-effect on some integrations with a data synchronization component, including ServiceNow.
What's the issue?
Basically, the ServiceNow integration is pre-configured to use '24x7' as the name for the default shift in every new group it creates in xMatters. As a result, there are several different outcomes, depending on the process you use:
- If you create a group in ServiceNow and then use the data sync feature to create the group in xMatters, the new group will have two shifts: a '24x7' shift which will contain the people specified in ServiceNow and an empty "Default Shift".
- If you update an existing group from ServiceNow and its counterpart in xMatters has the '24x7 shift, the data sync will update the members in the '24x7' shift.
- If you update an existing group from ServiceNow but the group in xMatters does not contain the '24x7 shift' (for example, if you created a new group in xMatters that has only the 'Default Shift'), the data sync adds the members to the group's roster, but does not add them to a shift.
What's the fix?
We're currently working on an updated version of the integration that will address this issue permanently, but there are a couple of workarounds that we recommend, depending on your situation.
If you are installing a new integration, you can follow the instructions in the ServiceNow integration article for modifying the xMattersConfig Script Include to change the default shift name for new groups to 'Default Shift'. You won't encounter any issues when creating or syncing groups.
If you have an existing integration, it's a little trickier...
The first option requires a little more effort (depending on how many groups you have in ServiceNow/xMatters), but also addresses the problem permanently:
- First, in xMatters, check your groups for any shifts still named '24x7', and rename them all to 'Default Shift'.
- Then, in ServiceNow, make the changes to the xMattersConfig Script Include described in the integration article to change the default shift name for new groups to 'Default Shift'.
This ensures that the sync correctly targets the 'Default Shift' with any updates to existing groups, and each new group it creates will have only one shift.
The second option is to simply accept that every new group the synchronization creates in xMatters will have two shifts: a populated '24x7' and an empty 'Default Shift'. After each group is created, you can delete the Default Shift (it won't get created again). We hope to have a resolution that will also address this approach in the future, but we do not yet have a time frame for its release.
xMatters internal reference: INTA-5409, COR-7083