1. xMatters
  2. Community
  3. Developers & Coders

Feature Request: "Escalate" through Sub-Group Members

Mike Lomax
Not Yet Reviewed

I have a very out-of-the-ordinary design for specific reason that apply to our organization and staffing.  However, the concepts I will share here and they way I will share them should make my feature request adaptable to many companies situations.  See "Today's Scenario #1 Process" below to understand the challenge I am trying to remedy for many of us.

Scenario #1 Design:

  • Primary Group members: Secondary Group 1, 15-minute Delay, Secondary Group 2, 15-minute Delay, Secondary Group 3, 15-minute Delay, …
  • Secondary Group 1 members: User A
  • Secondary Group 2 members: User B
  • Secondary Group 3 members: User C

 

Today’s Scenario #1 Process:

  • Notification comes in to Primary Group and targets first member, Secondary Group 1.
  • Process moves from Primary Group to Secondary Group 1 where it finds User A and sends the notification to User A.
  • User A responds with Escalate.
  • Process finds that there are no other members of Secondary Group 1 and moves back up to the Primary Group.
  • In the Primary Group, the process finds the 15-minute delay and waits for the 15-minutes to expire before starting the process to notify the next Primary Group member.
    • User A asked that the process Escalate to the next User.  My opinion is that the process should not complete the Escalate process until if finds that next User.

 

Proposed Scenario #1 Process:

  • Notification comes in to Primary Group and targets first member, Secondary Group 1.
  • Process moves from Primary Group to Secondary Group 1 where it finds User A and sends the notification to User A.
  • User A responds with Escalate.
  • Process finds that there are no other members of Secondary Group 1 and moves back up to the Primary Group.
  • In the Primary Group, the process skips over the 15-minute delay due to the Escalate order from User A.
  • The process then finds Secondary Group 2 as the next member of the Primary Group.
  • Process moves from the Primary Group to Secondary Group2 where it finds User B and sends the notification to User B.

 

While some could argue that this design would not work with a situation where there were multiple User members in the Secondary Groups with delays between them, I contend that it would and present Scenario #2 to describe that.

 

Scenario #2 Design:

  • Primary Group members: Secondary Group 1, 15-minute Delay, Secondary Group 2, 15-minute Delay, Secondary Group 3, 15-minute Delay, …
  • Secondary Group 1 members: User A, 2-minute Delay, User B
  • Secondary Group 2 members: User C, 2-minute Delay, User D
  • Secondary Group 3 members: User E, 2-minute Delay, User F

 

Proposed Scenario #2 Process:

  • Notification comes in to Primary Group and targets first member, Secondary Group 1.
  • Process moves from Primary Group to Secondary Group 1 where it finds User A and sends the notification to User A.
  • User A responds with Escalate.
  • Process next skips the Secondary Group 1 2-minute Delay due to the Escalate Order from User A.
  • The process next finds User B in Secondary Group 1 and sends the notification to User B.
  • User B also responds with Escalate.
  • Process finds that there are no other members of Secondary Group 1 and moves back up to the Primary Group.
  • In the Primary Group, the process skips over the 15-minute delay due to the Escalate order from User B.
  • The process then finds Secondary Group 2 as the next member of the Primary Group.
  • Process moves from the Primary Group to Secondary Group2 where it finds User C and sends the notification to User C.

If you are interested in why our company would benefit from this design, read my Comment below.

 

Mike

0

Comments

2 comments
Date Votes

Please sign in to leave a comment.

  • Mike Lomax

    My company’s particular situation is this:

    • We are a Global company and use xM for our Global Department.
    • xM notification triggers are sent in from SolarWinds Orion, Remedyforce and Major Incident notifications to all Department staff.
    • Our Global Department is made up of multiple Teams with different IT responsibilities.
      • These Teams have Business Hours they keep, say 8 AM to 5 PM ET, but some Team members are On-Duty starting before or after those Business Hours.
      • Team is requesting change from blanket notification to all Team members for Critical notifications to a Rotation design where a different staff member each week takes lead and receives the notification first.  If that first notified Team member is busy, they can Escalate to the person in the Rotation that will cover the following week.  However, if that first Team member does not respond within 5-minutes, the whole Team gets the notification.
    • We have always strived to simplify xM Administration as much as possible which includes:
      • Work Hours:
        • Things are always changing with staff work hours.  Our department is very flexible and allows staff members to choose their work hours including their lunch length.  This together with attrition and new staff coming on, maintaining multiple Team related Groups Shifts can be a nightmare.
      • Group Holidays:
        • In addition, the Group Holidays feature was useless to use because Teams span throughout many countries around the world.
      • Solution:
        • To remedy this and ease administration of the Team Groups, I created On-Duty Hours Groups.  Each department staff member has their own On-Duty Hours Group which outlines what their work hours are as well as the Holidays they observe.  Hence the reason for using Secondary Groups in the Scenarios above.

    Mike

    0
  • Craig Gulliver

    Thanks Mike for the detailed request. This sounds similar to a tiered support model where each level can escalate to the next tier if necessary.

    I've been talking with our CSM team about getting together with you soon and digging into the details.

    0

Didn't find what you were looking for?

New post