Integrating with Fresh Service

FreshService is a cloud-based IT Help Desk and service management solution that enables organizations to simplify their IT operations. The solution offers features that include a ticketing system, self-service portal and knowledge-base.

eG Enterprise is capable of integrating with Freshservice via its REST API. eG alerts are automatically routed to Freshservice by making appropriate API calls, resulting in the automatic creation of trouble tickets in Freshservice. If an eG alert changes or is closed, the corresponding ticket in Freshservice is also automatically updated/closed (as the case may be).

To integrate the eG manager with Freshservice, follow the steps below:

Login to the eG administrative interface.
Select the Manager option from the Settings tile.
Figure 3 will then appear. From the manager settings tree in the left panel of Figure 3, select the ITSM/Collaboration Integration node. The third-party ITSM/Collaboration tools that eG Enterprise can integrate with will be listed in the right panel.

Figure 3 : Viewing the ITSM/Collaboration tool options
Now, click on the Fresh Serviceoption in the right panel (see Figure 3). An Fresh Service section will now appear in the right panel (see Figure 4).

Figure 4 : Configuring integration with Freshservice
To enable integration with Freshservice, first slide the Fresh Service slider in Figure 4 to the right.

Then, specify the following in Figure 4:

REST Endpoint: eG Enterprise integrates with Freshservice using REST API. The eG manager POSTs eG alerts to the endpoint URL of the API as JSON payloads containing alert information. To enable the eG manager to connect to the API, you need to specify the endpoint URL here.
User and Password: Freshservice uses Basic Access Authorization. This means, for authentication, you can use the same username and password you use when logging into your helpdesk. Specify that user name and password here.
Issue type: Specify how trouble tickets created from eG alerts are to be classified in Freshservice. The default value is Incident.
Requester Email: When creating a trouble ticket in Freshservice, the email ID of the person who reported a problem and requested a ticket has to be provided. Therefore, specify the email ID that should be displayed as the 'requester email ID' in all trouble tickets that are automatically created in Freshservice against eG alerts.
Category and Sub Category: Freshservice allows structuring trouble tickets using Category and Sub-category. Proper categorization allows automated workflow rules, SLA mapping, and better incident management. Using the Category and Sub Category fields, indicate how you want the trouble tickets created for eG alerts to be categorized.

Subject: Specify the format of the subject of eG alerts routed to Freshservice. The default format is as follows:

$prior - $ctype / $cname - $pdesc

The ‘dollared’ ($) text in the format above is a key, the value of which varies at run time, depending upon the information contained in the eG alarms. For example, in the default format above, $prior is a key that represents the priority/severity of an eG alert, and changes according to the actual priority of the eG alerts sent to Freshservce. You are advised against changing any of the key names.

The other keys that are part of the default format are discussed in the table below:

$cname	Will display the name of the problem component
$ctype	Will display the problem component type
$pdesc	Will display a brief problem description

Description Format and Problem description: Use these parameters to indicate the format in which problem information should be communicated by the eG manager to Freshservice. By default, the Description Format flag is set to Concise. In this case, the Problem description will be of the format indicated by Figure 5 below:

Figure 5 : The Concise Problem Description

The Concise Problem description, as you can see, is characterized by a list of label : variable pairs. In each pair, the 'label' is a static value that qualifies/describes the value of the 'variable' that follows. The 'variable' on the other hand will be substituted at run time by relevant alert information. For instance, in the pair Alert Description : $pdesc, 'Alert Description' is the static label that will be sent as is to MS Teams. This label implies that the value that follows it will be a brief problem description. The variable $pdesc will be replaced at run time by the actual problem description contained within the corresponding alarm. You can change 'labels' if you so need, but you are advised against changing the variable names.

If you set the Description Format to Descriptive instead, then, by default, the Problem description you see in Figure 6 will be displayed.

Figure 6 : The Descriptive Problem description

Unlike the Concise format, where key elements of the alert information are listed one after another, the Descriptive format reads like a 'meaningful problem statement. It is structured like a sentence, with variables embedded within. These variables will assume actual values at run time. Here again, you are free to play around with the sentence structure, but are advised against changing the variable names.

Regardless of the format you choose, the following variables apply by default:

$cname	The name of the problem component
$ctype	The component type to which the problem component belongs
$pdesc	A brief description of the problem
$layer	The problematic layer
$prior	The problem priority/severity
$starttime	The date/time at which the problem was first detected

If required, you can override the default Problem description, so it includes additional problem details. For that, click on the

icon alongside Problem description. This will open Figure 7.

Figure 7 : Selecting the details to be included in the Problem description

Say, you want the problem description to include the name of the business service that was impacted by the problem condition. In this case, select Service Affected from Figure 7 and click the SELECT button. The Problem description will then change as depicted by Figure 8 below:

Figure 8 : Problem description changed to include Service Affected

Custom Payload: Use custom payload to customize the alert information you send to Freshservice, so that it includes additional static information.

Typically, the details of an eG alert are sent as a JSON file to the configured URL. Every piece of information contained within an eG alert - eg., priority, component name, component type etc. - is represented in the JSON file as a $key:$value pair, where 'key' denotes the alert field, and 'value' denotes the actual value of that field at run time. The 'key' is configured based on the keys supported by the Freshservice REST API. For instance, if the REST API represents alarm priorities using the key 'prior', then the same key will be used in the JSON file for denoting alarm priorities. Accordingly, the entry for alarm priority in the JSON file will be $prior:$value. The $value will be Critical, Major, Minor, or Normal, depending upon the actual priority of the alarm being sent.

First, check whether the Freshservice REST API supports a 'key' that can be used for capturing the 'source' of alerts/incidents. If no such key exists, then you cannot proceed with the Custom Payload configuration. On the other hand, if such a key is available, then proceed to replace the $key in your Custom Payload specification, with that key value. For the purpose of our example, let us assume that the REST API supports the key named 'source'. In this case therefore, substitute '$key' with 'source'.

Then, proceed to explicitly specify the FQDN of your eG manager in the place of $value. This is because, you can use the Custom Payload configuration to add only 'static' information - i.e., information that you explicitly configure, and hence will never change. In the case of our example therefore, the $value will be egmanager.innovations.com.

The complete Custom Payload specification will now be: source:egmanager.innovations.com

Finally, click the Update button in .