How to use Ticket-based IT Experience with non-IT tickets

By default, feedback context data can be mapped from the incident and requested item tables. With some scripting, it is possible to map data beyond the predefined tables to HappySignals.

The overall process for collecting feedback for ServiceNow processes is two-fold:
1) sending the data to HappySignals and
2) getting the data back to ServiceNow with the HappySignals API
Sending the data to HappySignals is fairly simple, but requires a bit of scripting to get the correct data from your desired table. The second part process is a bit more complicated, it requires customisation of the HappySignals application in ServiceNow and the level of customisation required depends on the available fields on the table.

An important thing to note is that the table you want to map ideally should extend the “Task” table in ServiceNow. Although, it is technically possible also to map tables that do not extend “Task”, this requires more customisation to the application. 

Sending data to HappySignals

Create a HappyCustomConfig script include

The first thing you need to do is to create a new script include in the Global application scope with the following details:
API name
Client callable
Accessible from
All application scopes
The HappyCustomConfig script include is used for generating a configuration object that contains the data that will be passed to HappySignals. The HappyCustomConfig can be used to create data mapping for custom tables or be used for script-based data fetching for the default tables. The example script below can be used as a starting point for making your custom table mappings.
var HappyCustomConfig = Class.create();
HappyCustomConfig.prototype = {
    initialize: function () {
        var currentTimeMS = new GlideDateTime().getNumericValue();
        this.datestamp = new Date(currentTimeMS).toISOString();

     * Configure function can override existing data mappings or  define mappings for tables not supported by the default configuration logic.
     * @param {GlideRecord} obj GlideRecord object that triggered response link creation
     * @param {JSON object} conf object that contains configurations made in HappyLinkCreator
     * @param {string} tableName name of the table where the GlideRecord object originated
     * @returns modified configuration object
    Configure: function (obj, conf, tableName) {

        /* Available keys on base object described below
        Below keys correspond to specific fields on HappySignals cloud
        conf.esm = 'IT'; // top level categorization for the response eg. IT, HR, Security
        conf.ticket_type = ''; // type of ticket eg. Request, Incident etc.
        conf.category = ''; // survey form key, consult with HappySignals
        conf.ticket_number = ''; // ticket number or other identifier
        conf.opened_at = ''; // time when the ticket was opened
        conf.datestamp = ''; // time for the survey delivery, should be tied to datetime field on the ticket
        conf.language = ''; // language code eg. en, fr, es etc.

        conf.contact_type = ''; = '';

        conf.employment_started_at = '';
        conf.endUserId = ''; // email address of the end-user

        // OTHER DETAILS
        conf.reassign = '';
        conf.assignment_group = '';
        conf.priority = '';
        conf.location = ''; = ''; = '';
        conf.service = '';
        conf.secondary_category = '';
        conf.tertiary_category = '';
        conf.region = '';
        conf.vendor = '';
        conf.business_stc = '';
        conf.time_worked = '';
        conf.made_sla = '';
        conf.source_object = '';
        conf.source_id = '';

        // short example of mapping interaction table fields
        switch (tableName) {
            case 'interaction':
                conf.esm = "IT";
                conf.ticket_type = "Interaction";
                conf.category = "other";
                conf.ticket_number = this.__getFieldValue(obj, 'number');
                conf.language = this.__getFieldValue(obj, 'opened_for.preferred_language');
                conf.datestamp = this.__getFieldValue(obj, 'closed_at', 'time');

                conf.contact_type = this.__getFieldValue(obj, 'type');
       = this.__getFieldValue(obj, '');

                conf.assignment_group = this.__getFieldValue(obj, 'assignment_group');

        return conf; // return the configuration object back to HappyLinkCreator to generate the response link

     * Gets field values and returns them in a format expected by HappySignals
     * @param {glideRecordObject} record gliderecord of the object where the field value is retrieved
     * @param {string} field field name where the data is retrieved, supports dot-walking to reference fields
     * @param {string} returnType in what type the value is returned, options sys_id, value, time, displayValue
     * @returns return value from the given field
    __getFieldValue: function (record, field, returnType) {

        returnType = returnType || 'displayValue'; // set default return type as displayValue if defining argument is not provided
        var returnValue = '', //set default return value
            elem = record.getElement(field); // get the possibly dot-walked element

        if (!gs.nil(elem) && !gs.nil(elem.toString())) {
            try {
                switch (returnType) {
                    case 'sys_id':
                        returnValue = elem.sys_id.toString();
                    case 'value':
                        returnValue = elem.toString();
                    case 'time':
                        var timeInMS = new GlideDateTime(elem.toString()).getNumericValue();
                        returnValue = new Date(timeInMS).toISOString(); // time fields need to be formatted to ISO8061 format
                        returnValue = elem.getDisplayValue();
            } catch (e) {
      "HappyCustomConfig: mapping for field ({0}) unsuccessfull due to error: {1}", field, e.message);
                return ''; // failsafe to prevent other field processing from stopping
            if (returnValue == undefined || returnValue == null) {
                returnValue = '';
        return returnValue;

    type: 'HappyCustomConfig'


Create a notification for your custom table
Once you have created the HappyCustomConfig script include then you need to add the HappySignals voting buttons to the email notifications for your custom table. The notifications determine when and who will receive the HappySignals feedback survey. 
To add the HappySignals voting buttons to your notifications simply add the following mail script to them:
Note that the feedback survey that is shown to the recipient after they click one of the voting buttons is the same as in the case of a general request.

Getting the feedback data back to HappySignals

This part applies only to application versions 1.4.0 and lower. For version 1.5.0 and higher please contact

The second part of the process is to get the feedback data related to your custom table back to ServiceNow. This consist of two parts, modifying the transform map so that fields in the HappySignals feedback table is filled correctly and displaying the data in HappySignals widgets.
To pull in non-IT responses from the HappySignal API you need add new values to a system property under the "General Properties" of the HappySignals application.
The values in this property must include the same values as you have defined for as the ESM class for your custom table.

Modify the Service Experience integration job

Modifying the integration only applies to application versions of 1.3.2 and lower.

If your custom table is related to a non-IT process such as HR or Finance and the ESM value that you pass to HappySignals is not “IT”, you will need to modify the HappySignals Integration Job to fetch the non-IT related feedbacks also. In the integration job you will need to modify the query parameters to include the ESM values you need, see the example below:
var esmValues = [





var esmQuery = '';

var timestampQuery = '';

var rest = new sn_ws.RESTMessageV2();

rest.setEndpoint(endpoint + '/api/v2/responses');


rest.setRequestHeader('Authorization', 'Bearer ' + gs.base64Encode(apikey));

rest.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded');

rest.setRequestHeader('Accept', 'application/json');

for (var i = 0, j = esmValues.length; i < j; i++) {

    if (esmQuery === '') {

        esmQuery += encodeURIComponent('enterpriseClass__in') + '=' + encodeURIComponent(esmValues[i]);

    } else {

        esmQuery += '&' + encodeURIComponent('enterpriseClass__in') + '=' + encodeURIComponent(esmValues[i])



if (timestamp > 0) {

    // Get only newer feedbacks than we already have

    timestampQuery = 'timestamp__gt=' + timestamp;


rest.setRequestBody(timestampQuery + '&' + esmQuery);

var response = rest.execute();

// now that we have the response
See our API documentation for more information about how to query the API.
Clone and modify the transform map “HappySignals Feedback Import”
The HappySignals API is used to fetch feedback data back to ServiceNow. In order to generate the feedback records and linked data to your ServiceNow instance a transform map is used. The application comes with a transform map that has defaults for incidents and requested items, but you will need to add your own logic to the transform map to get your custom table to work.
We suggest that you make a duplicate of the existing transform map, modify the duplicate and then deactivate the original map.
This way when we publish updates to the application the changes you have made to the transform map are not overwritten by the update. The transform map that you need to duplicate and modify is named “HappySignals Feedback Import”.

Showing the feedbacks on HappySignals widgets

Note that the following section only applies to ticket records that extend the “Task” table in ServiceNow. Currently, there is no way to customise the script that constructs the feedback widget contents and what fields it checks for widget content values. Below is a list of the field that the script checks on the ticket record to fill the values.
Unfortunately, if your custom ticket record does not have the reference fields that the content script tries to use, the script execution will stop and the feedback won’t be visible on the agent widget. If you need to show the feedbacks on the agent widget and do not have the necessary fields on the custom record contact us at 
Value on the widget
Field on the ticket record
Defaults to “Request” with custom tables
start_time = sys_created_on
end_time = closed_at
resolved_by or closed_by
A valid field check is done against the ticket record table