Proactive IT Experience 2.0.0 Update Guide

This article walks you through the update process for HappySignals Proactive IT Experience version 2.0.0 for ServiceNow.

Outline

1. Review Release notes
2. Update the application
   
   1. Fix scripts
3. Review application update log
   
   1. Resolving update conflicts
   2. Deletions on this update
4. Review Fix Script logs
5. Review changes to core application components
   
   1. Email Notifications
      1. Notification conditions
   2. Notification Email Scripts
      1. happy_it_ex_vote
      2. happy_it_ex_apps_list
   3. Script Includes
      1. HappyItExLinkCreator
      2. HappyProactiveConstants
      3. Scripted Extension Point
6. Post update checks
7. HappySignals Support
8. New functionalities
9. Other Changes

Review Release notes

Before you start you update journey, review the release notes for the new application version to get an overview of the changes introduced.

See the release notes at Proactive IT Experience 2.0.0 - September 2025

Update the application

After you’ve reviewed the release notes, its time to update your application.

Always updated your non-production environment first, then go through the steps and actions outline in this article and only then move to update your production environment. As a general rule, the less customizations you have on the application the easier your updated will be.

To update the application within your ServiceNow instance navigate to System Applications > All Available Applications > Installed. In the list find the application you want to update and click "Update".

Fix Scripts

Fix scripts are used to migrate data from an existing data model to new one when the application functionality requires it. Fix scripts run once during the update process but are not run again in subsequent updates.

Some fix script executions may take a while to finish, depending on how many records the script needs to process, so be patient while waiting the updated to finish. You can track the fix script progression in the system logs by looking at log entries starting the application name “HappySignals Proactive IT Experience”.

HappySignals - Migrate Audiences

This script will go through all existing Survey Settings records and try to migrate the existing survey target audience rules to our new audience definition model. The script will log the migration results to system logs. Note that in some cases you will need to migrate some surveys manually.

HappySignals - Migrate Enterprise Apps

This script will go through all existing Survey Settings records where the survey is Enterprise Applications and the Application Category field is not empty. The migration will read all the applications that have been set for survey and will try to migrate them to the new survey vocabulary model. The script will log the migration results to system logs.

HappySignals - Update Survey Run Records

This script will update Survey Run records that have been created within the last 365 days so new survey functionality critical fields are populated. The script has a hard-cap to only update 250 thousand records at one run. The script will log the migration progression and completion. If your survey runs table holds more than 250 thousand records that have been created within the last 365 days, then you need to run this fix script manually until all needed records have been updated.

Review application update log

Once the update has completed, review the update log to verify which application components have been skipped during the update due to customizations.

To review application update logs click on the ""View update log" after the update.

Resolving update conflicts

When reviewing and resolving update conflicts within your instance there are some of general rules that will help you to evaluate which decision to take:

• If the conflict is on “configuration record” such as System Property, you can mark the record as “Reviewed” without further action. Configuration records are expected to be modified we do not want to override the values you’ve set for them.
• If the conflict is on a “deleted record” and we’ve listed in this update guide, then resolve the conflict by using “Revert to Base System” to apply the deletion.
• Overall try to stay as close to OOB application as possible by using “Revert to Base System” version whenever possible.
• If the conflict is on a script record (script include, mail script, portal widget etc.), review the records individually and merge your customizations to our OOB version if you need to retain them otherwise use the action “Revert to Base System”.

If you are in doubt of what to do, feel free contact the HappySignals support at support@happysignals.com and provide them the list or content of conflicted records for review.

Deletions on this update

Following application files have been deleted in this release. Apply by these deletions manually by resolving the upgrade conflicts using the "Revert to Base System" option.

sys_documentation_it_experience_vocabulary_import_set__en
sys_script_60c5c0a7878a4210b59bcb3c8bbb35c3
sys_security_acl_role_c700ceb91bf87d10d688c80f034bcbdb
sys_dictionary_it_experience_vocabulary_import_set_NULL
sys_documentation_x_pgo_happy_it_ex_happysignals_survey_settings_main_application_en
ua_table_licensing_config_d4e89acc2b0b6250e767f622d891bf66
sys_security_acl_cf004ab91bf87d10d688c80f034bcb82
sys_db_object_dd37171a93130a10c668b0ed1dba108a

Review Fix Script logs

Once you’ve resolved update conflicts, its time to verify the fix script migrations that were done during the update process.

Navigate to your ServiceNow instance’s system logs “System Logs —> System Log —> All”. In the log list filter the log entries using "Source = x_pgo_happy_it_ex" and "Message contains migration”.

Review the log entries to see which migrations have been successful and make a note of any logs that indicate a requirement for manual migration steps like updating target audiences on some survey settings records or running the “HappySignals - Update Survey Run Records” fix script again.

Once you’ve reviewed the migration logs, plan and apply the manual migration steps as needed.

Review core component breaking changes

This version introduces changes in the core application components that may break custom components that you have in your instance. Review the changes below and make sure to update your custom components when needed.

Email notifications

All notifications for the Survey Runs table

• All notifications for Proactive IT Experience have been updated to use new condition set. New base conditions are “Status Changes to Send Ready”. See the example for Office Environment survey notification.

  

  As the email notifications for HappySignals Proactive Surveys have likely been modified and possibly cloned within your instances, make sure to review all of them and update the conditions to match the new base conditions to ensure app functions correctly after the update.

Notifications “Happy IT Single Application” and “Happy IT Multiple Applications”

In addition to the new base condition, these two notifications have had other conditions changed. See the new notification conditions below.

• Happy IT Single Application

  

• Happy IT Multiple Applications

  

Email notification scripts

happy_it_ex_vote

Contents of this script has changed, but script output remains the same. If you have modified the script, proposed action is to:

1. Evaluate what has been customised within the script.
   1. Usually customisations involve a change color of the rating scale..
2. Revert the script to its “Base System” version.
3. Move the changes depending on what has been modified.
   1. Button Text Color change —> Application General Properties
   2. Changes to button HTML or color coding —> HappyProactiveConstants Script Include
   3. Other code changes within the script —> Merge changes to new the “Base System” version. If in doubt, contact HappySignals Support and provide them with your customised email script version.

happy_it_ex_apps_list

Script content has changed, but script output still remains the same. If you have modified the script, evaluate your changes against our OOB version and merge your changes in as necessary.

happy_it_ex_apps_default_app_name

This script has been deprecated. Replace any instances of this script within notification contents with a field reference on the email content.

// Replace all instances of this:
${happy_it_ex_apps_default_app_name}

// With this:
${survey_settings.main_item}

Script Includes

HappyItExLinkCreator

This version changes the structure and methods of the HappyItExLinkCreator class quite a bit.

Breaking change introduced in this version of the script:

createLink() method now returns object instead of a URL string.

The object contains the created survey URL and GlideRecord object of the survey record. If you have custom components within your system that use the HappyItExLinkCreator method make sure to update them to support the new return object.

See the examples below:

// createLink() function now returns and object with survey URL
// and GlideRecord object of the survey
{
  url:survey link, 
  survey_record: Survey GlideRecord
}

// Example survey link creation call BEFORE the update
var happyLinkCreator = new HappyItExLinkCreator();
var url = happyLinkCreator.createLink(current)

// Example survey link creation call AFTER the update
var happyLinkCreator = new HappyItExLinkCreator();
var survey = happyLinkCreator.createLink(current)
if(gs.nil(survey) || gs.nil(survey.url) {
  gs.warn("Something went wrong with survey URL creation");
  return;
}
var url = survey.url;

global.HappyItExCustomConfig() Script Includes are no longer called directly from the HappyItExLinkCreator().

To re-enable the use for data mapping HappyItExCustomConfig() you must register it as a Scripted Extension Point.

Register your existing HappyItExCustomConfig() as a extension point navigate to “Extension Instances” table (sys_extension_instance).

Use sys_extension_instance.list command in the application navigator to open a list of registered extension points.

Click on “New” on te list to register new extension point implementation.

On the form fill in the following details and click “Submit”

HappyProactiveConstants

This version introduces new configuration Script Include called HappyProactiveConstants. This is your centralised script for controlling more complex application settings. After the application update there couple of key constants to modify on your HappyProactiveConstants script include.

Instance connection validation

ServiceNow non-production instances sometimes establish unwanted connections to HappySignals production resources. This typically happens due to misconfigured clone protections or when temporary instances are created from backups.

To prevent these invalid connections, HappyProactiveConstants includes INSTANCE_MAP and TEAMS_TENANT_MAP constants that validate whether your current instance is connecting to its expected counterpart on HappySignals. In case of a mismatch or missing configuration, your instance will not make outbound connection calls to the configured HappySignals resource.

HappyProactiveConstants.INSTANCE_MAP

Use this constant to map all your ServiceNow instances to their corresponding HappySignals environments.

/** HappyProactiveConstants.INSTANCE_MAP 
 * Used to check if connection is valid when sending survey sent notifications to HappySignals.
 * Note that survey link generation is not dependent on this map and it only impacts the survey sent notifications.
 * The map structure is: {'ServiceNow instance name': 'HappySignals tenant URL'} */
HappyProactiveConstants.INSTANCE_MAP = {
    'your-dev-instance-name': '<https://your-dev.test.happysignals.com>',
    'your-test-instance-name': '<https://your-test.test.happysignals.com>',
    'your-prod-instance-name': '<https://your-prod.emea.happysignals.com>'
}

// EXAMPLE MAPPING
HappyProactiveConstants.INSTANCE_MAP = {
    'happysignalsdev': 'https://happysignalsdev.test.happysignals.com',
    'happysignalsqa': 'https://happysignalstest.test.happysignals.com',
    'happysignals': 'https://happysignals.emea.happysignals.com'
}

HappyProactiveConstants.TEAMS_TENANT_MAP

Use this constant to map all your ServiceNow instances to their corresponding Entra Tenant IDs when using HappySignals Surveys via Teams.

Note that the Entra Tenant ID differs from your Entra ID. The tenant ID is generated when you register HappySurveys via Teams in your Entra environment.

// HappyProactiveConstants.TEAMS_TENANT_MAP
// Used to check if the instance connection is valid when sending Teams messages.
// The map structure is: {'ServiceNow instance name': 'Entra tenant ID'}
HappyProactiveConstants.TEAMS_TENANT_MAP = {
    'your-servicenow-instance-name': 'your-entra-tenant-id',
}

// EXAMPLE MAPPING
HappyProactiveConstants.TEAMS_TENANT_MAP = {
    'happysignalsdev': '463d7efb-5fba-4d85-9a94-18ad02352f39',
    'happysignalsqa': '94a92cba-7dd1-4ece-bf72-8e4b5a5cbf7e',
    'happysignals': '3049ecc2-f6cf-481e-8c52-0608a30ef301'
}

Post update checks

After any application update there are couple of key things to do:

1. Review the application Scheduled Jobs and re-activate them if needed.
   1. Sometimes during application updates, Scheduled Jobs within the application scope become inactive. Therefore its important to re-active any jobs that might have become inactive.
2. Execute functional testing in a non-production environment prior to updating production instance.

HappySignals Support

If you encounter issues, have questions or need support with the update contact our support at

support@happysignals.com

New Functionalities

This application version brings a whole host of new functionalities and improvements to the application.

New target audience management

The survey target audience management has been completely revamped. The new audience management model allows for greater flexibility and better performance for audience management.

New audience selection model starts by selecting a “Audience Table”. Audience table can be any table that has reference field(s) to User table within ServiceNow.

By default the audience tables have a limited selection, but your organisations ServiceNow administrators can expand the selection as needed.

Once Audience Table has been selected, the user is prompted to select who is the survey recipient on the selected table. The “Survey Recipient” will show all fields from the table that reference a User.

Once the “Audience Table” and “Survey Recipient” are selected, you can then narrow down your audience using the “Audience Filter” field. On the Audience filter you can narrow down your audience by setting the criteria for the survey audience.

If left empty, all “Survey Recipients” found in the “Audience Table” will be part of the survey audience.

Note that every survey includes a base filter which narrows the audience to active users who have an email address registered within the system.

After selecting your audience and saving the survey settings record following fields will update:

• Target Audience —> Link to the “Audience Table” within ServiceNow listing the source records.
• Audience Size —> How many unique users there are in the audience.
• Daily Surveys (avg) —> How many surveys are sent out daily with the current Audience Size and selected Survey Frequency.

Survey scheduling based on recipient timezone

New survey scheduling logic is introduced in this release. Survey will always be sent at the same local time of day regardless of the where the user might be in the world.

To set the time of day for survey delivery and enable use of recipient timezone navigate to “Integration Settings —> General Properties” and look for the two settings below.

Survey scheduling example

Example survey processing and scheduling where surveys are delivered at 9 AM local time daily.

• Recipient 1 resides in Singapore with timezone of UTC+8
• Recipient 2 resides in Eastern US with timezone of UTC-5
• Survey are set to be processed at 11 AM UTC in ServiceNow

Survey processing begins 11 AM UTC (7 PM UTC+8 and 6 AM UTC-5),

• For Recipient 1 9 AM local time has already passed for today, so their survey is scheduled to be delivered the next day at 9 AM UTC+8 (1 AM UTC)
• For Recipient 2 9 AM local time has not passed yet for today, so their survey is scheduled to be sent the same day at 9 AM UTC-5 (1 PM UTC)

How does the system determine delivery timezone

Timezone that is used to determine local delivery time is three stepped:

1. If enabled, the application checks for a timezone selected by the recipient in ServiceNow and schedules the survey based on the selection.
2. If the recipient does not have timezone selected, survey will be scheduled based on the timezone set on the survey settings.
3. If neither of the above points set a timezone for survey delivery, system timezone will be used.

Specific Application Surveys

New logic has been introduced to manage surveys where feedback is asked about a specific enterprise application(s).

A new survey type “Specific Application” has been introduced for survey settings.

When selected, you are prompted to select to which category the application belongs. Available categories are created dynamically based on “Survey Vocabularies” (see the next chapter for Vocabulary management).

Once “Category” has been selected, use the “Main Item” to pick which application you want to ask feedback about on this survey.

With the “Main Item” selected you can optionally add alternative application options to which the recipients may also provide feedback.

Survey Vocabularies

Another change related to “Specific Application” surveys is the introduction of a Survey Vocabulary model in this release. Survey Vocabulary allows you to create and manage items that are used within the HappySignals Proactive Surveys. Each vocabulary item can be linked to records within your ServiceNow so they can be associated with internal services, configuration items etc.

In this release the two types of vocabulary items that you can create and manage are Applications and AI Tools.

Each vocabulary item requires the following details:

Additionally, you can add following data to the items:

Surveys via Teams

This release brings the option to send HappySignal proactive surveys via HappySignals Surveys via Teams bot.

Manage the survey delivery to Teams within application settings “Surveys via Teams —> Settings” and the survey message content under “Surveys via Teams —> Greeting Messages”.

New Application Menu Structure

This release revamps the application menu structure and brings a whole host of new application menu items.

Other Changes

Default Data Preservers

Application now ships with a data preserver for excluding connection system properties from system clones.

Performance improvements

Survey processing done by application has been optimised reducing the execution time of the daily processing job.

Language code mapping

HappyProactiveConstants Script Include has a language code map to manage language code differences HappySignals and ServiceNow when using Surveys via Teams.

/** HappyProactiveConstants.LANGUAGE_CODE_MAP
 * Used in HappySurveySender to lookup correct Greeting Message template in sys_ui_message table when HappySignals language code differs from ServiceNow language code.
 * Language codes supported by HappySignals available at <https://support.happysignals.com/which-languages-are-available>
 * Structure of the map is: {'happySignals language code': 'ServiceNow language code'} 
*/
HappyProactiveConstants.LANGUAGE_CODE_MAP = {
    'pt-br': 'pb', // Brazilian Portuguese
    'no': 'nb', // Norwegian
};

Rating button templating

Email rating buttons scales have been moved to HappyProactiveConstants Script Include.

Table Changes

This release brings some changes to the application table data model. See the listed changes in the tables below.

HappySignals Survey Runs Table

HappySignals Survey Settings Table

ACL Changes

New field level ACLs introduced to the Survey Runs table.