It is ServiceNow’s new release season! With the Orlando release in Early Access, we will show some platform features and enhancements that are a bit more admin focused. Typically the Developer Blog is focused on application development, but handling the instance and data also is sometimes done by developers.
Configuring clones can take significant time, depending on how many instances and the complexity of the setup required. Clone profiles have been introduced in Orlando to help simplify and automate the process. The profile allows you to set up different procedures for different instances/types of instances. Each profile has its settings for the general clone configurations. A new set of related lists allows for configuring Exclusions, Preservers, and Cleanup scripts.
The initial system_profile is not editable and is used to house the default exclusions, preservers, and cleanup scripts. You can adjust the related items to the system_profile to set up the components that are shared between all clone profiles. After creating new profiles and new related records like clean scripts, they can be added via the related list Edit button. An order field is now available on top of profiles for cleanup_scripts. The order field allows for correctly ordering cleanup scripts so that no out of order or dependencies are missed.
Clone Preserve update sets
You read that right. Preserve in progress update sets is now available. A new setting for clones is a checkbox that allows you to select to preserve any in-progress update sets from the last 90 days in the target instance. You do need to be still concerned about completed update sets that have not made it up the pipeline to the clone source (typically production). The update sets are imported into the retrieved update set table and need to be previewed/committed to be deployed.
Preserve Large tables
It is not always understood the implications of preserving large tables during a clone. ServiceNow would also like to understand the use cases around choosing to preserve those types of tables data. To help with both of those points upon choosing to maintain large tables, a secondary prompt will appear. It will tell you which tables are large and ask for why you are wanting to copy so much data.
Scheduled Jobs TimeZones
Timezones can be scary. Don’t fear; this addition should be helpful. The sysauto and sys_trigger tables both contain two new fields.
*Timezone time_zone *Time entered_time
The two above fields will be used together to allow for a user to enter in time, and time zone, and have that be when the scheduled job will run. The time field is using a new field type UTC, which will not adjust the entered time based on the user’s session as most time fields.
ServiceNow and the community have put together tons of checklists and white papers on cloning. I wanted to call out a couple of things to help out that is not required. Before cloning and periodically, it is useful to Batch together older update sets. Sort your local update set list with no parent and older than a month, create a new parent called ‘QX 202x batch’. Set all the update sets in your list to that parent. The reduction in update sets that need to be compared will be reduced and will speed the retrieval of update sets post clone. Next, you can set all the update sets with no parent to ignore. The ignore is done to prevent your instances from trying to retrieve these already retrieved update sets. The local update sets in production have unique sys_id’s and would otherwise be retrieved after cloning