Introduction #
When cloning a ServiceNow instance, the goal for any Quality Clouds (QC) customer is to maintain a functional scanning environment in the clone target instance with minimal manual intervention.
Because the QC application involves both Scoped elements (from the Store) and
Global components (installed via the Global Component Installer), as well as a number of system properties, user identities, and user-to-group assignments, the strategy you choose for your production instance directly impacts your post-clone workload.
Background: The Installation Process #
To understand the cloning options, it is important to first recognize what a “full” installation entails. Beyond installing the app from the ServiceNow Store, the following must be configured:
1. Identity & Auth Profile for Global Components Installer:
A temporary local identity with read/write access and the admin and script_writer (from Zurich version onwards) roles needs to be created to run the Global Component Installer. This is associated with a REST Auth Profile included with the Application.
Note: this identity is only required to run the Global Component installer. It can be deactivated or deleted immediately after the Global Components have been installed.
2. Global Component Installation:
This process uses the identity above to copy application files from the QC scope into the Global Scope via the REST API. This adds custom Quality Clouds views and UI actions to standard code editing forms (Business Rules, Script Includes, etc.).
3. Permanent Identities:
Creation of the dedicated Read-Only and Read/Write users required for ongoing QC operations.
- The Read-only user (user with the snc_readonly role) is required to support full scans of the instance, and needs to be entered in the Quality Clouds portal when the instance is registered in the portal.
- The Read/Write user is required to enable automatic updates of the status of Update Set LiveChecks
4. System Properties:
Specific QC system properties must be defined to point the instance to the correct QC API endpoints and settings. The read/write userʼs ServiceNow user Id and password also need to be set as system properties.
5. Initial connection to Quality Clouds:
A user with the Customer Admin role in the Quality Clouds portal authenticates from ServiceNow into the Quality Clouds environment using their Quality Clouds portal credentials. This creates a “seed” token in the ServiceNow instance, which is used to create individual authentication tokens for all ServiceNow users, which are added to the QC Users group (or to any other existing group in the instance, if so configured by the customer)
6. User to Group assignment:
All developers who will be using the Quality Clouds application features need to be added to the “QC Users” group. This automatically creates authentication tokens for them (as long as the initial connection to Quality Clouds has been successful). In addition, users designated as write-off approvers must be added to the “Quality Clouds Peer Reviewers” group.
Cloning Prerequisites #
The “Option Zero” Warning: If the Quality Clouds application is not installed in the clone source (Production) instance, a clone will completely wipe the application from the target (Development).
You will be forced to perform a full “from-scratch” installation after every clone. This is not recommended
Data Preservers & Clone Exclusions #
The Quality Clouds application from version 13.1 onwards includes the following data preservers and clone exclusions configurations:
These will only take effect when the application is installed in the production or clone source instance. Assuming that these are in place and that there is no customer-specific clone configuration that overwrites them, the following clone preparation strategies can be considered
Clone preparation options for Customers #
If the Quality Clouds application is present in the Production instance, customers have two primary strategies:
Option 1: The “Ready-to-Go” Strategy (Recommended) #
In this scenario, the customer performs the full configuration (Global Component Installation, System Properties, and Identities) in the Production instance, even if they do not intend to use the application functionality in this instance.
- Impact on Production: Low. It adds QC-specific views and UI actions to code forms, but does not alter core ServiceNow logic, performance, or fullfiller user experience.
- Clone Outcome: When performed with the Clone Exclusions and Data Preservers, included in version 13.1 of the application, the target instance (Dev) emerges from the clone with a fully functional QC setup if Dev users / passwords / groups are preserved during the clone (see section below).
- Post-Clone Work: Near zero.
Option 2: The “Minimal Production Footprint” Strategy #
The customer installs the QC application from the Store in Production but does not run the Global Component Installer or perform any additional configuration there.
- Impact on Production: Minimal. Only the scoped application exists; no Global Scope changes are made.
- Clone Outcome: The Global Components will be missing in the target instance after the clone because they did not exist in the source.
- Post-Clone Work: Medium. You must re-create the temporary user identity and authentication profile configuration required to re-run the Global Component Installer in the Dev instance after every clone, and perform the Global Component installation. Also, depending on whether the Dev users/passwords / groups are preserved during the clone, additional tasks may be required (see section below)
Users/groups/roles configuration during the clone #
The Quality Clouds application requires the read/write and read-only users to be properly configured in the clone target instance after the clone. Also, the assignment of developers to the “QC Users” and of Peer Reviewers to the “Quality Clouds Peer Reviewers” groups would ideally be preserved during a clone in order to cause the minimum disruption possible to development tasks. These are settings that are not dependent on which of the above strategies is chosen.
In general, users and groups may or may not be overwritten with a clone, and each customer can be expected to manage this according to their own policies. However, the combination of the two strategies above and the way in which users and groups are managed during the clone does mean that the following scenarios are possible.
Other configurations not included in Data Preservers / Clone Exclusions #
Regardless of the option chosen, these additional environment-specific settings must be managed to ensure that the Quality Clouds application keeps working smoothly after a clone:
