The Escalations/Notifications sub-section lets Administrators set protocols through which Users are notified about predefined Events. This functionality is very flexible and allows PCR-360 to monitor your operations, automate your Workflow, and notify appropriate people when Events occur (or are about to occur). Determine the needed Escalations and Notifications. Once you have determined the Escalations and Notifications that you want to create, notifications should be created first, then Escalations.

By establishing a system of Escalations and Notifications, Administrators can ensure, for instance, that all parties to a Workflow receive Notifications when that Workflow is approaching its due date. Or, if a Service Desk item has been left untouched for an extended period of time, supervisors can be notified so action can be taken to address it. There are dozens of actions (or inaction) in the application that can initialize an Escalation chain.

Escalations and Notifications are executed by Events generated by activity in Service Desk, Inventory, Billing, system internals, etc. Events are generated by various conditions of the data as it changes (or doesn't) over time. For example, if the system receives an email that is registered as an Inquiry, an Event is generated. When the Inquiry is opened by a User for review, that also generates an Event. If the Inquiry is converted to an Incident or Service Order or is Voided, all of those generate their own Event.

In this section, we explain Escalations (the process that is triggered by a defined Event) and build custom Notifications that alert Users that the Event has already completed or will complete soon.

Notifications

Since Notifications must be built before they can be used in Escalations, we'll cover them first.

When building an Escalation, you define certain actions for Escalation to follow including sending a message to relevant parties. This section covers how to define a specific Notification to send; the Notifications Grid (see image above) allows you to add, edit, and delete those Notifications that can be sent by an Escalation.

Adding a Notification

There are a number of standard Notifications that come pre-built in PCR-360. Sometimes, however, these can be insufficient for an organization's needs.

To add a new notification that can be sent by an Escalation, click located on the Grid Toolbar.

In the Notification form (see image above), you must define several required fields.

First, select an Event from a list of possible events. The selected 'Event' in this field corresponds directly to the Start Event of an Escalation. When a User selects the 'Start Event' for an Escalation, only Notifications whose 'Event' matches the 'Start Event' specified for the Escalation are available to set in Sequence actions (explained below).

Next, set a Title and Subject and choose contacts the Notification can be sent to via the To, Cc, and Bcc fields.

Finally, enter content into the text editor in the field labeled Body. This represents the content of the Notification itself.

Setting "Hash Variables"

Notifications are essentially email/system message templates. You can fill in the generic text that is used each time the Notification is sent out, but you can also set placeholders for actual data to be set into the message before it is sent.

In the Notification's fields, you can use various text strings surrounded by "##" to hold the place for a piece of data replaces it when the message is generated & sent out. We call these "Hash Variables". Based on the Event selected for the Notification, the list of Hash Variables you can use changes (located in the drop-down list below the Body area). Please don't use any ##...## text patterns not found on the list. For example, if you add "##THIS_IS_NOT_VALID##" to the message body, it is replaced with nothing when the Notification is populated with data.

Select a Hash Variable from the list, click . If you want to add formatting, selecting content around it and using the editor's toolbar.

You can also add certain Hash Variables to the header fields (To, Cc, and Bcc). Type "##" in one of the fields to see what Hash Variables are available for that field. Note: you must select the Notification's Event before this works. You can add Hash Variables to the Subject, but you'll have to type them in by hand. Examine the list of available Variables and type them into the Subject (don't forget "##" on each end!). This is remedied in a future update.

Lastly, in order to make the Notification available for Escalations, check the "For Escalation" checkbox. Notifications can be used for several purposes but must be specifically made available to Escalations when intended for that purpose. If you assign a Notification to an Escalation Sequence, come back to _uncheck_ the For Escalation box, you receive a prompt warning you the Notification will be removed from any Escalation Sequences to which it was assigned. If you continue, the Sequences may fail as they no longer have access to the Notification. Make sure you reassign Escalation Sequences to different Notifications or remove the Sequence before performing this action.

Saving the New Notification

Once all required are filled and other fields are completed as desired, click . The new Notification appears as an item on the Grid and can be selected when you build an Escalation with a corresponding Start Event.

Editing Existing Notifications

You can edit existing Notifications by double-clicking on any item on the Notifications Grid or by selecting an item and clicking located immediately above the grid.

You can make desired changes to the Notification. The Event assigned to the Notification cannot be changed, as it must match the Start Event for any Escalations that use it. If you wish to use the same template content for a different Event, use the form's Options menu, and click Copy to New Form:

This sets up the same content for a new Notification where you can now change the Event. NOTE: You may need to clean up Hash Variables you used in the original Notification that are invalid for the new Event you select. Once all required fields have been satisfied, click at the bottom of the form.

You can delete existing Notifications by selecting the appropriate item on the Notifications grid and clicking located immediately above the grid. Once a Notification is deleted from the Grid, it can no longer be selected as a 'Notification' when adding an action to an Escalation Sequence.

Notifications Log

To see a comprehensive history of all the Notifications that have been sent throughout your organization, open the Notification Log Grid. You cannot add, edit, or delete items on this grid, but you can double-click any item in the grid to see the content of the actual message that was sent:

Escalations

Escalations are automated tasks that execute a series of predefined actions once the task is started. The Escalation is initialized by an Event generated from some data change in the system. Escalations are defined by:

Start Event (required) – Event that begins the Escalation's life cycle
Abort Events (optional) – Events which can interrupt the Escalation to prevent unnecessary actions from occurring
Sequences (required) – Actions the Escalation takes during its life cycle
Criteria (optional) – A means of narrowing down the conditions under which the Escalation begins

Adding an Escalation

Navigate to the Escalations Grid: Open the Admin navigation tab, click the Escalations/Notifications node, and then click Escalations.

To add a new Escalation, click the add button located on the Grid Toolbar.

In the Escalation form, you must complete the required fields. Enter an "Escalation Name" so that the new Escalation can easily be identified.

Select a "Start Event" from the list of events. The Start Event is the purpose for the Escalation and, when triggered, begins the Escalation's life cycle. For example, a User could select _Service Desk Workflow Assigned_ as the Start Event. In this instance, the Escalation process would begin whenever an SD item's Workflow is assigned to one or more Workers. Notice that the list of possible events includes both System events – those delivered as part of PCR-360 as well as User-Defined Events which may be created by you (discussed below).

You can also select one or more Abort Events. When a specified Abort Event occurs – say, Service Desk Workflow Completed – the Escalation process ends, no further sequences processes, and no further notifications is sent. A little later, we'll discuss creating Escalation Sequence Events: custom Events generated by an Escalation that can be used to abort other Escalations.

Saving the New Escalation

Once all required fields in the Escalation data entry form have been satisfied, click the Save New button . The new Escalation appears as an item on the Escalations grid. If the Escalation is set to "Active", the Escalation commences whenever its Start Event occurs.

Editing Existing Escalation

You can edit existing Escalations by double-clicking on any item on the Escalations grid or by selecting an item and clicking the Save New button located immediately above the Grid.

In the Escalation data entry form, you can define the item's inputs by following the protocol established earlier in this section. You cannot change the Start Event for an existing Escalation. If you wish to define an Escalation identical or similar without reproducing all the steps to create it, use the form's Options menu to create a copy:

Admin users can delete existing escalations by selecting the appropriate item(s) on the Escalations grid and clicking the Delete Selected button located immediately above the Grid.

Building an Escalation Sequence

Next, you can add a Sequence of actions that occur once the Escalation process begins. In the image above, see the tab labeled Sequence. To add an action to the Sequence, click the Add button located on the Sequence grid toolbar.

In the form (see image above), you must complete the required fields.

The Sequence # determines the order in which each action is performed by the application. For example, if a User were to add three actions to the Sequence and each action had a Sequence # of '100', '200', and '300', the application would execute the '100' action before moving on to the '200', etc. The application lets you enter arbitrary numbers so you can come back to add Sequences in the middle without having to renumber all the existing ones after it. You may also duplicate the Sequence # if you wish to execute two actions simultaneously.

You can select a Type of action to define what action is taken for the Sequence:

Generate Incident: A new Incident is added to Service Desk with the supplied CSR, Trouble Code, and Details from this Sequence action.
Workgroup: Uses the Workgroup from the Service Desk Workflow entry that triggered the Escalation (below) to send Notifications to each person in the Workgroup's Sequence tab.
]
Notify: Sends a selected Notification to a specified list of recipients (Notify To).
]
A couple of tips for using this Type:
1. You may leave Notify To empty to use the Notification's predefined recipients.
2. If you set a list of recipients here, they are used instead of those set on the Notification.
Esc. Sequence Event: Generate a custom Event that can abort other Escalations or send out Notifications for specific conditions.
]

Sequence Events are best used with Criteria (discussed below ) so they are only generated when very specific data conditions are met. With these narrowed conditions, you gain more control over aborting certain Escalations or whether to send particular Notifications.

Time to Wait defines how long the Sequence action waits from the point it is initialized before it executes. For example:

10:00 : Escalation begins, Sequence 100 has TTW of "5m"
10:05 : Sequence 100 executes. Escalation increments to Sequence 200 with TTW "15m"
10:20 : Sequence 200 executes. Escalation increments to 300 with TTW "1h"
11:20 : Sequence 300 executes. Escalation completes.

You can monitor Escalation activity on the Escalation Log Grid (located in the same menu as the Escalation management Grid).

If you define Type as either "Notify" or "Workgroup", you are prompted to select a Notification that is sent. Select a Notification from the list of existing notifications by clicking on the Search Icon in the appropriate field. Available Notifications must match the Escalation's Start Event you specified.

For "_Workgroup_" Type, the selected Notification is sent to all members of the Workgroup on the originating object (Service Desk, Inventory, etc.).
For "_Notify_" Type, you must specify who should receive the Notification.

If you define the Type as "Generate Incident", Service Rep and Problem Description fields become available. A good example of a "Generate Incident" notification would be when maintenance for a piece of inventory is due, you can create an Incident Report so that there is a Notification and Workflow item created to ensure maintenance is started for that item.

Escalation Sequence Events

If you set Type to "Esc. Sequence Event", you are required to give the custom event a name. Only letters, numbers, and spaces are allowed here. The purpose of a Sequence Event is to make a custom Event that other Escalations can use as one of their Abort Events. Sequence Events can be tricky to understand, but they add even more power to the automation of your Escalation actions. This feature needs a little more detail to explain, but it helps to understand Criteria first.

Escalation Criteria

In addition to specifying a series of actions for an Escalation, you may want to restrict the conditions under which those actions are executed. Criteria act as a filter (think of the Grid's Search and Filter mechanisms) that prevent an Escalation from beginning unless the data provided matches its conditions.

On the Escalation form, click the Criteria tab, and click the Add button . On the Criteria form, you can set a single condition using a piece of Data (that is provided to the Event info) to match against, a Comparison operator, and the Value the data must match to pass and begin the Escalation. Based on the Data field, the Value may be an arbitrary text value, a Picker item, an option from a drop-down, etc.

If you add multiple Criteria rows, they are treated with an "AND" connection, meaning all the Criteria must match against the Start Event's data for the Escalation to begin. Be careful how you construct your Criteria so that you don't end up matching nothing and the Escalation never starts.

NOTE: If an Escalation is already in progress and you add/change/delete Criteria, the changes _do not_ affect the progression of the current instance of the Escalation. Criteria are only tested for starting the Escalation.

Escalation Sequence Events

Sequence Events are most useful when coupled with Criteria (below) so that the custom event is generated when specific conditions for the event's Escalation are met.

There are currently two ways to utilize a Sequence Event once you've created it:

Set it as the Event that generates Notifications. Just as some System Events can automatically generate Notifications (alerting a Worker they have been assigned to a Service Order, sending an Administrator notice when a Purchase Order is approved, etc.), Sequence Events can do the same, utilizing the power of Criteria to generate the Notification to specific conditions. For instance, Jeff requested he not be sent Workflow Assignment emails because he has the Service Desk's "Assigned Workflow" Grid open with an auto-refresh Perspective so he can see new assignments as they come in. Set them as Abort Events on other Escalations. Using System Events to abort an Escalation aborts that Escalation regardless of the situation – which is often desirable. However, using Criteria gives you control over the conditions under which the Sequence Event is generated so the targeted Escalation only aborts under the defined Criteria. In this use-case, the chain of events looks like this:

System Event A starts Escalation A that has 3 Sequences.
- One of the Abort Events for Escalation A is Abort Esc A (defined in Escalation B)
- Sequence 100 executes, and Sequence 200 is now waiting for its Time To Wait. You'll see Escalation A in the Escalation Log with a Status of 'In Progress'.
System Event B is generated and triggered
- Escalation B is watching for System Event B and, based on the Criteria defined for the Escalation, starts its Sequences
  - Its first Sequence is the Event Abort Esc A with TTW of 0m – it executes immediately.
    - The Sequence Event is triggered: the system looks for any Escalations that should abort because of this custom event. It finds Escalation A is currently running ('In Progress') and waiting to execute Sequence 200.
    - The system marks Escalation A as 'ABORTED', and the Sequence Event completes.
  - Escalation B has no other Sequences, so it is marked COMPLETE.
- Escalation A Sequence 200 reaches its TTW and attempts to execute
  - The system first checks the status of its Escalation (A) and sees it has been aborted.
    - Sequence 200 is canceled
    - The system does not increment the Sequence for Escalation A. It is finished with Status "Aborted" in the Escalation Log.

Escalation Sequence Events Example

A customer emails the Service Desk, and the Inquiry is converted to an Order. The initial Workflow is assigned to Mary.
- The assignment begins an Escalation ('Workflow Assignment – Action Required') that sends Mary an email.
- A second Sequence waits 30 minutes before sending a message to her Workgroup Manager.
  - The Escalation already has "Service Desk Item Viewed" selected as an Abort Event. Once anyone opens the Incident, the Escalation stops, and her manager does not get an email.
Ten minutes after the Workflow was assigned, the Requester emails again: Please cancel the original request.
- The CSR opens the Service Desk item and changes its status to "Void".
- The actual results:
  1. Mary's manager doesn't get an email because the CSR opened the Incident, not Mary.
  2. The Escalation that would send an email to her Manager should be aborted.
  3. Mary should be notified of the voided item (but only when it's been VOIDED, not just that its status changed).

We have a problem here. Anyone who opens the Incident cancels the Escalation. Even if it's just the CSR making minor edits, Mary's manager won't get an email if she lets it go too long. But we don't want to remove the Abort Event altogether. We want the 'Viewed' event to abort this Escalation for a specific person'viewing the Incident, Mary. We also want to abort it if the CSR goes in and Voids the Incident, but only for that Status change.

How to accomplish these? Sequence Events. We can set up other Escalations with Criteria to generate an event when the SD Status changes specifically to 'Void' or when the person viewing the Incident is specifically Mary. We'll need two other Escalations for this because the conditions we need to meet are exclusive from each other.

Add a new Escalation:
- Name it "Abort for SD Status Void".
- Select the ServiceDesk Item Status Changed for the Start Event.
Add a new Sequence:
- Select a Type of "Esc. Sequence Event".
- Name the event "SD Item Voided".
- Set the Time-To-Wait to 0m. This causes it to trigger as quickly as possible.
Save & Close the form.
This Escalation generates the Custom Event any time a Service Desk Item's Status changes. At this point, you are close, but not quite what you want. On the Criteria tab, add a new Criteria:
- Give it a Description like "SD Status is Void".
- From the Data list, select "SD_STATUS". Use the Equals Comparison option.
- When the SD Status Value list updates, select "Void".
- Save the Criteria.
Save and Close this Escalation.

Now, any time a Service Desk Item's Status is changed specifically to 'Void', this Escalation begins. Its only Sequence generates the custom "SD Item Voided" event. Now, let's make sure the manager's email is only sent if Mary doesn't view the Incident she's assigned.

Click to start another new Escalation:
- Name it "Abort for Assigned Worker Viewed".
- Select "Service Desk Item Viewed" as the Start Event.
Add a Sequence:
- Name it "Worker Viewed SD Item".
- Select Type Esc. Sequence Event.
- Name it "Assigned Worker Viewed SD Item".
- Set Time To Wait to 0m to make it trigger as soon as possible.
Save and Close the Sequence form.
Click the Criteria tab the click the add button to start a new Criteria:
- Give it a Description like "Viewed By Assigned Worker".
- From the Data list, select the "global" variable "EVENT_CONTACT" – this is the person who initiated the event. In the case of this Escalation, it is the person who viewed the SD Item.
- Select 'Equals' from the Comparison list.
- To make this custom Event more reusable, we use another Hash Variable for the comparison value rather than specifically picking Mary. Type "##" in the value input and choose "##SDWF_WORKER##". This represents the "Service Desk Workflow Worker" Contact which we want to match the person who viewed the SD Item (EVENT_CONTACT).
Save and Close the Criteria.
Save and Close the Escalation.

Now, we need to use these specialized Sequence Events:

Open the Escalation you'll want to abort using the custom event. In our example, "Workflow Assignment – Action Required".
On the Abort Events list, scroll to the bottom. You'll see a group called "Esc. Sequence Events" with the new custom events listed. Check them and uncheck the generic "Service Desk Item Viewed" event because we require more specific conditions to abort this Escalation. Save and Close the Escalation.

There are now two custom events that can cancel this Escalation: one is a System Event, and the other is custom-generated from an Escalation using Criteria.

Exchanging Data With External Data Stores (REST)

Service Host REST Escalations are Specialized Escalation Sequences that can be used to interface with outside data sources. Read more here: Exchanging Data With External Data Stores .

Escalations Log

To see a comprehensive history of all the Escalations that have been triggered throughout your organization, open the Escalations Log Grid. You cannot add, edit, or delete items on this Grid, but it serves as a handy tool for querying and reporting on all escalations.

User-Defined Events (UDEs)

As of version 2.1.4.0 this functionality is deprecated and removed. This system was never used, and PCR-360 has outgrown the initial design of this feature. Moving forward please see the newly added Custom Logic: Events functionality which has enhanced PCR-360's ability to handle customized logic.

As previously explained, when building an Escalation, you must first define a "Start Event" that triggers the Escalation process. While you can select a "Start Event" from a number of system-defined events, you can also build and select highly specific events not predefined by the system. These are called User-Defined Events. For example, your organization wants to purchase manufacturer’s maintenance on equipment once the warranty date expires and have PCR-360 send a notification before the warranty ends. With PCR-360, you may create a UDE that monitors the warranty end date value for equipment and generate a Notification when that date is within 'x' days of ending. UDEs are listed as items on the User-Defined Events Grid (see image above). Go to Admin > Escalations/Notifications > User Defined Events.

Adding a User-Defined Event

To add a new UDE that can be selected as an Escalation Start Event, click the add button located on the Grid Toolbar.

In the UDE form, you must define several required fields.

First, set an Event Name. This name is displayed on the list of available Start Events when building an Escalation.

Next, define the Event Type as Service Desk or Inventory. Once a type has been selected, you are able to refine the Event to specific Service Desk or Inventory items in the Conditions tab to enable you to be very specific with your UDEs.

In the Watch Type field, define which aspect of the Event Type is being watched. Define whether the Escalation is triggered by Count, Date, or Change. Selecting Change compares current and new data values are to see what is different.

If you select "Count" as the Watch Type, you must also enter a numeric Threshold. If the Threshold is reached, it triggers the Escalation. You must also define a Frequency, the rate at which the application monitors the Count For example, you may want to check rapidly-changing data more frequently to catch matching conditions as soon as they're available or less frequently if the watched condition doesn't change often. If you select "Date" as the Watch Type, you can further define the specific date by selecting a choice from the Watch Column field. If you select "Changed" as the Watch Type, you can check or uncheck the box next to the Include New field. This indicates whether or not newly-created items are considered "changes" that start the Escalation.

You can also apply the UDE to specific Service Desk items and pieces of equipment. When you select "Service Desk" as the Event Type, it limits the UDE to items of a certain SD Status and SD Type. For example, a UDE can apply solely to Pending (SD Status) Service Orders (SD Type). When you select "Equipment" as the Event Type, it limits the UDE to a specific Equipment Catalog and from a specific Warehouse.

Saving a User-Defined Event

Once all required fields have been satisfied, click the save new button . The new User-Defined Event appears on the Grid and can be selected as a Start Event when building an Escalation.

Editing Existing User-defined Events

You can edit existing User-Defined Events by double-clicking on any item on the grid or by selecting an item and clicking the Edit Selected button located immediately above the Grid.

This action opens the item's User-Defined Event form where you can change permitted inputs by following the protocol established earlier in this section. Once all required fields have been satisfied, click the Save button at the bottom of the form.

You can delete existing User-Defined Events by selecting the appropriate item on the Grid and clicking the Delete Selected located immediately above the grid. Once a User-Defined Event is deleted, it can no longer be selected as an 'Event Type' when building an Escalation.

Browser not supported