Automation of HelpDesk request processing based on SharePoint declarative workflows​​​

Introduction

The main task of the technical support service is to ensure a permanent quality level of the services furnished. If the tech support load is relatively low, maintaining service quality is easy. However, with the increasing load, as well as complicating structure of the service itself, problems of the process automation move to the forefront.

Traditionally, the basis for describing the service quality is Service License Agreements (SLA). The SLA description is often given in various agreements and other normative documents. For example, a service agreement may include the following table:

Maintenance Support Service Response Times & Resolution Efforts

The given table indicates how fast the requests addressed to the service should be processed, depending on the specific request parameters.

If you look closely at the above table, you can see that time intervals describing the tech support rate of response to the requests received and rate of problem solution act as the main characteristics describing the service quality. This is explained by the fact these values are almost the only objectively measurable values which directly affect the service quality. All other characteristics such as the quality of solutions provided, their relevance and conformity with the referred questions can be estimated only subjectively, e.g. can be described using formal attributes.

In view of the above, when implementing automated request processing in HarePoint HelpDesk, the goal of ensuring the observance of two measured service quality characteristics such as response time of the tech support personnel and time of the solution provision, was pursued. In HarePoint HelpDesk the response time is the rate of formation of any comment to the request. The moment when the request status takes the value Resolved is chosen as the time of solution formation.

Automation of the service provision quality control is implemented in HarePoint HelpDesk solely with the help of SharePoint declarative workflows.

To simplify the configuration of the request processing logic, a part of settings is moved to separate configurable rules – SLA Rules. These rules are processed exclusively in the context of declarative workflows. On the one hand, such an approach makes it possible to significantly simplify the product configuration in typical cases, and at the same time enables a substantial finishing in atypical cases.

A set of rules is formed on the settings page of the product:

If you look closely at this figure, the similarity of the shown SLA list of rules to the table at the beginning of the article will become obvious.

Each SLA rule consists of 4 groups of parameters.

The first group contains parameters identifying the rule: SLA Name and SLA Description. They are necessary for its proper display in the list of rules.

The second group contains a description of the rule eligibility criteria. Only requests that meet this criterion will be handled according to the appropriate rule. It should be noted that the sequence is important in selecting the SLA rule. The rule at the top of the list is applied first, and so on. This means that if the rule eligibility criterion is too “mild”, it can lead to that the rules going below will be ignored.

The third group defines two measurable parameters of the service provision: response and resolutions time. Date and time before which you should generate a response or solution will be calculated on the basis of these parameters. Date/time of response is stored in the request field Response DueBy Time, while the date/time of the solution formation is stored in field DueBy Date. Working time recording can be disabled for the rule in the calculation of the specified times – to do so you should check the box ‘Should be resolved irrespective of operational hours’.

The fourth group of parameters describes actions performed in the request escalation. These actions can be performed both before and after the DueBy time has elapsed. Either simple notification of a tech support employee or automatic assignment or change of the request priority is possible in the escalation. After the Response DueBy time has expired, only one level of escalation is possible. After the expiry of DueBy Date, 4 levels of escalation are possible, and the time of implementation of each level is counted from the DueBy Date moment.

Let us now consider how the described SLA rules are handled by the HarePoint HelpDesk workflows.

The current product version contains the following workflows:

1. HarePoint Helpdesk v2 – Assigning Support Rep
   The workflow automatically assigns a person responsible for processing the request in accordance with the request category. If the responsible person cannot be assigned automatically, the process tracks a timely appointment manually by sending appropriate notices. The workflow starts automatically after a new request is created.
2. HarePoint HelpDesk v2 – Evaluate SLA
   The workflow defines the SLA rule. In accordance with the rule found, the workflow calculate parameters DueBy Date and Response DueBy Time. The calculated dates, as well as the identifier of the actual SLA rule, are saved to the corresponding request fields. The workflow starts after the creation or modification of the request.
3. HarePoint HelpDesk v2 – Check SLA
   The workflow controls the timeliness of responses and finding of the problem solution described in the request. Dates DueBy Date and Response DueBy Time, calculated by workflow HarePoint HelpDesk v2 – Evaluate SLA are used as criteria. If conditions described in the SLA rules are infringed, the workflow performs escalations and other actions described in the rules. Besides, the process controls the procedure of approval of the solution found by the user. The workflow starts after the creation or modification of the request.
4. HarePoint HelpDesk v2 – Escalation
   A workflow that escalates request if an actual SLA rule is infringed. It starts in the absence of a timely generated response or solution. The workflow starts automatically in the context of another workflow HarePoint HelpDesk v2 – Check SLA.

As it has been mentioned before, the request processing mechanism according to SLA rules makes it possible to implement a large number of typical scenarios of the tech support service work. However, there are cases which can not be described with the help of SLA rules. In this case, it is necessary to modify the workflows that are contained in HarePoint HelpDesk.

To modify HarePoint HelpDesk workflows, it is necessary to use regular tools for the SharePoint node administration – Microsoft SharePoint Designer.

In order to get acquainted with the peculiarities of workflows in details, or to change any of them, you need to perform the following steps:

1. In menu Site Actions of the HarePoint HelpDesk site select Edit in SharePoint Designer.

2. In window Navigation of Microsoft SharePoint Designer click Workflows.

3. All workflows included into HarePoint HelpDesk have the appropriate prefix.

4. Select the necessary workflow, in the Customization section click link Edit workflow.

5. Make necessary changes to the workflow and click Publish in the ribbon.

Let us consider the work of processes in more detail.

HarePoint Helpdesk v2 – Assigning Support Rep

The workflow body is divided into two big logical steps.

The first step, Auto assigning by Category, tries to automatically match a person responsible for the request processing, according to the created request category. It makes sense to edit this step in case it is necessary to change the logic of automatic assignment of the responsible person. For example, the responsible person can be assigned on the basis of Product, Mode field or according to any other attribute. It should also be noted that in addition to assignment any other operations can be performed. For example, it is possible to change any request properties, create a service element in another list, etc.

Step Waiting for manual assigning is performed when the responsible person cannot be chosen automatically. This part of the workflow reminds tech support employees twice about the need to assign a responsible person manually. After the second reminder the workflow ends. A time period within which reminders must be made is set in the product settings and is called ‘Request Assigning time-out’.

HarePoint HelpDesk v2 – Evaluate SLA

The workflow computes the identifier of the SLA rule and calculates DueBy dates. The computation of the SLA rule is performed each time after the request creation or modification.

If the request is closed, e.g. its status is not equal to value Open, the workflow stops immediately.

The computation of the SLA rule identifier is performed with the help of activity HHD Evaluate SLA rule:

If no rule can be matched to the request parameters, the specified activity returns value -1. The workflow also ends. If a rule is found, then its identifier is saved to the SLA Rule request field:

Once the identifier of the SLA rule has been found, date/time calculation is performed for request fields DueBy Date and Response DueBy Time. The calculation of these parameters is performed during the steps Evaluate DueBy Date and Evaluate Response DueBy Time, respectively.

It should also be mentioned that, depending on the rule settings, working time is either considered or not considered in DueBy time calculation. It looks as follows in the workflow listing:

The obtained values DueBy are rounded to minutes (seconds are discarded) and saved in the corresponding fields of the request.

HarePoint HelpDesk v2 – Check SLA

The workflow describes two important processes of the request processing automation: control of conditions fulfillment of the SLA rule computed by the HarePoint HelpDesk v2 – Evaluate SLA workflow and process of approval of the resolution provided to the user.

The workflow is launched each time when the request is created or modified.

If the request is closed, e.g. its status is not equal to value Open, the workflow stops immediately.

All the processes of the SLA rules control and implementation are performed at step Implementing solution:

The first thing you should pay attention to in the above workflow fragment is complicated activity Wait for Field Change in Current Item by SLA rule (highlighted with the frame). This activity suspends the execution of a workflow until an expected condition is met.

In this case, the waiting will be finished when the request status is equal to value Resolved or Closed. However, waiting can be finished for other reasons as well. First, the SLA rule identifier can be changed, secondly – Due By Date can increase.

The result of the completed activity returns the variable’s value. The following values can be assigned to this variable.

1. matchcondition – waiting for the condition to be fulfilled.
2. slarulechanged -while waiting, the SLA rule changed. The SLA rule identifier is taken from the SLA Rule field from the Requests list.
3. duebyisincreased – a change (increase) in the date and time assigned in the Due By Date field in the Requests lists.

Essentially, the whole step Implementing solution is waiting for a resolution and subsequent analysis of the waiting results.

Another important nuance of activity ‘Wait for Field Change in Current Item by SLA rule work’ is that in the process of waiting escalations are performed according to the specified SLA rule. From a technical point of view, escalation is a launch of another workflow – HarePoint HelpDesk v2 – Escalation. When launching the escalation process, escalation parameters derived from the current rule are transferred to it. Pattern of the workflow name is transferred in the form of regular expression «^HarePoint HelpDesk v2 – Escalation(\.v[\d\.]+)?$». The regular expression is used for taking into account the number of version of the escalation workflow.

Everything that follows after the step Implementing solution describes the process of approval of the provided resolution by the user and does not need any special comments.

HarePoint HelpDesk v2 – Escalation

The workflow of request escalation starts in the process of waiting for a resolution using activity ‘Wait for Field Change in Current Item by SLA rule’.

At the start, two parameters formed on the basis of current SLA rule are transferred to the process:

• escalationId
  String identifier of escalation. String formed according to the rule:
  {SLA Rule Name}-[Response|Resolution]-Level{Number}
  • SLA Rule Name
    Rule name
  • Response|Resolution
    Escalation type. Response – Escalation when the respond time is out. Resolution – Escalation when the resolution time is out.
  • Number
    For escalation of type Response only value «1» is possible. For type Resolution – values from «1» to «4».
  • Example: SLA Rule for High Priority-Response-Level1.
• escalationDetails
  String in the XML format. Example: <?xml version=”1.0″?>
  <Escalation xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” xmlns:xsd=”http://www.w3.org/2001/XMLSchema” Type=”AfterTimeout” User=”MAPILAB\voronkov” Level=”1″ UniqueName=”SLA Rule for High Priority-Response-Level1″>
  <Time>0</Time>
  <AdditionActions>
  <MLEscalationAction Type=”AssignToSupportRep” Argument=”MAPILAB\voronkov” />
  </AdditionActions>
  </Escalation>

To work with parameter escalationDetails, you can use a special activity – HHD Get Escalation property:

Activity ‘HHD Get Escalation property’ accepts an escalation property name and data as an input parameter. In the present version of HarePoint HelpDesk only value EscalationRecipient may be used as an input parameter. A string expression returned, in this case, contains a full e-mail address of the recipient of the notification on the escalation of type «Sergey Voronkov [[email protected]]»

Another activity – HHD Run Escalation actions, also receive data of escalation as an input parameter. This activity performs a set of additional actions at the request escalation:

Conclusion

The mechanism of declarative processes implemented in products of the SharePoint family provides a unique opportunity for automation of a very wide range of tasks. The uniqueness lies in the fact that at the input we have a rather convenient and rapid method for finishing any process directly in the customer’s office, and at the output, we obtain a programming .net module which is ready for the implementation. Since the module has been already compiled, the rate of implementation of declarative workflow procedures is confidently comparable to the rate of implementation of modules that are built using Visual Studio.

Using Microsoft SharePoint Designer, you can modify workflows adding additional steps on preliminary request processing to them, complement or modify algorithms of the SLA rules processing, modify the request escalation workflow and do many other things. And all this can be done without the use of Visual Studio and programming.

For additional information on HarePoint HelpDesk workflows and description of activities supplied with the product please refer to the documentation.