Helping message senders get the job done

A notification platform should enable a sender to quickly send the right message to the appropriate recipients; in addition to being efficient, it's also important to be accurate. To do both of these things, it is useful to limit the recipients that your sender can see, and prepare custom communications in advance.

There may be many reasons for restricting the visibility of message forms to users, or limiting communications between a subset of users and a particular message sender. For example, you may want to:

• Designate a specific person in your company to send official updates during a major incident.
• Limit a sender to those communications customized for specific sites or geographical areas.
• Restrict which users can access and notify particular groups of users.

In this article, we use a major incident example to illustrate how you can use roles and product permissions, message scenarios, and groups or dynamic teams to control who can access customized communications, and the users they are able to target.

Example: Major Incident Management

XYZ Finance Co. is a large financial company that offers a variety of web services and online tools to its customers. If a major incident occurs, the company's incident manager is responsible for coordinating resolution of the incident, including all communications to internal and external stakeholders.

One of the incident manager's responsibilities is to initiate a conference bridge to remain open as a communication channel between groups working to resolve the issue. We'll use this conference bridge invitation as an example to illustrate how to limit custom communications between a particular sender and specific users, according to the following general framework:

1. Define a new Incident Manager role
2. Assign the Incident Manager role to a user
3. Define message recipients
4. Customize communications for incident managers

If you'd like to learn more about the topics being described, click the online help links that are embedded throughout the article. You can also click on any image to see a larger version.

1. Define a new Incident Manager role

We'll create a new 'Incident Manager' role to control the messages that are visible to the incident manager, and to restrict other users from having access to official major incident communications forms.

Roles are accessed from the Admin tab, under the Permissions menu. If you can't see this menu item in xMatters, then you may need to ask your administrator to create the role for you.

To create a new role:

1. On the Admin tab, under the Permissions menu, click Roles.
2. Click Add New at the top of the list of existing roles.
3. Name the role 'Incident Manager'.
4. Under Permissions on Other Roles, click Use Person for each type of user expected to be a recipient of major incident notifications. For example:

5. Under Permissions Other Roles Have, allow the Company Supervisor to Assign Role:

6. Click Save.
7. On the Functions for this Role page, select Run Reports and Send Messages from the list of available functions, and click Add to move them to the list of selected functions.

8. Click Save, and then click Save again.

2. Assign the Incident Manager role to a user

Now that we've created the Incident Manager role with the ability to run reports and send messages to the appropriate people, we'll assign this new role to the employee at XYZ Finance whose responsibility it is to act as the incident manager when a major incident occurs.

Note: If you're using a data synchronization process to load or synchronize users from another system, you may need to assign the Incident Manager role as part of the data synchronization job.

To assign a role to a user:

1. On the Users tab, click the name of the user you want assign the role.
2. On the user's user profile, click the Roles tab.
3. Add the Incident Manager role to the roles assigned to the user:

4. Click Save.
5. Repeat this process to assign the role to additional users, if desired.

3. Define message recipients

The incident manager needs to engage the appropriate resources to join the conference bridge when a major incident occurs. The nature of the major incident will influence which employees or other contacts the incident manager needs to invite to join the bridge; resources may also need to be engaged at different times throughout the resolution process.

Groups

Employees at XYZ Finance are organized into groups based on their department or skill-set within the company. Groups are contacted as a single entity, and based on the shift schedules, and escalation and rotation rules of the members in the group, members that are actively on duty or on-call will be notified. You can limit which users are able to send notifications to groups by configuring particular roles as group observers.

For example, XYZ Finance allows all users to send notifications to certain groups, like Customer Service, but they limit who is able to send notifications to others, like the Executives group. We'll add the Incident Manager role as an observer to the Executives group, so that the incident manager can invite the Executives that are on duty to act as advisors on the major incident conference bridge.

To add a group observer:

1. On the Groups tab, click the name of the group you want to modify (the 'Executives' group, in this case).
2. On the Overview page, click the Edit link next to Observers.
3. Clear the Observed By All check box, and then select the roles that you want to be able to observe this group (in this case, the Company Supervisor and the Incident Manager).
4. Click Save.

Dynamic Teams

Another method for characterizing and selecting users is with dynamic teams. Dynamic teams are created based on custom attributes, and are automatically populated to include members that match specified criteria at the time of an event (unlike groups, which only contain users that have specifically been added).

• For example, if XYZ Finance has multiple sites and needs to contact all users at a specific location, they could create a dynamic team based on a site or location field. When the dynamic team based on a specified value for the site attribute (e.g., site = Chicago) is notified, xMatters checks the database to determine who belongs to the team and should receive the alert.

4. Customize communications for incident managers

In the event of a major incident, it's important that the incident manager initiate the conference bridge as quickly as possible to begin the resolution process. To facilitate this, XYZ Finance has pre-configured messages for different scenarios that contain the appropriate contacts and bridge information.

The following screenshot shows an example of a major incident message scenario (a pre-filled copy) for a Core Network Switch Failure major incident. This scenario includes the groups the incident manager needs to initially get on the bridge for this incident, properties that can be used to quickly populate the message with details about the incident, and an xMatters conference bridge.

Here's a preview of the resulting message that would be sent to recipients, after the incident manager has filled out the property fields:

Manage recipients

In the example above, the message sender can see and edit the message recipients, so that they can re-use the scenario to send updates or invite additional users to the bridge at different points throughout the resolution process. For other communications, XYZ Finance may want to restrict users from being able to see or manage message recipients, by hiding the Recipient section of the form.

To hide the recipients section from a message form, click the Visible/Hidden icon (the eye icon) associated with the recipients section on the form's layout tab:

Scenario Permissions

Finally, XYZ Finance would like to restrict access to these message forms to prevent employees other than the incident manager from editing or initiating them. If a user doesn't have scenario initiator permission for a particular scenario, they are not able to see that scenario in the list of available scenarios when sending a form. We'll use scenario permissions to make this scenario visible to the Incident Manager role.

 To assign a role as an initiator of the scenario:

1. On the Messaging tab, click the name of the scenario (e.g., "Core Network Switch Failure") to open the scenario form.
2. From the Scenario drop-down menu, select Permissions to open the Scenario Permissions dialog box.
3. Type the role Incident Manager into the search box, and select to add it to the list of scenario initiators.

• If you want users with the scenario initiator permission to be able to edit the scenario when sending the form, you must explicitly grant them the edit scenario permission.

This article presents just one example of how various features and functionality of xMatters can be used to help message senders do their job more efficiently and effectively. Are there ways you can implement roles, product permissions, groups or dynamic teams, and custom communications to help message senders in your organization get the job done?

 xMatters reference: DTN-5191, DTN-5290, DOC-5895