Existing ServiceNow customers often have a location hierarchy defined in the cmn_location table with this data being used in existing business applications. SN Workplace Service Delivery requires location data in specific Workplace Locations extensions tables. To bridge this gap, an option is to create new WSD location records, which creates redundant records. Another option is to write scripts to migrate existing records to the WSD hierarchy.
The Workplace Service Delivery Location Migration minimizes the abovesaid effort to migrate hierarchies in cmn_location over to WSD tables by using configuration and eliminating the need for custom code.
Product documentation can be found here: https://docs.servicenow.com/en-US/bundle/sandiego-employee-service-management/page/product/workplace...
Important points to note:
After the Location Migration job is complete, sys_ids are preserved for migrated location records. Since WSD tables are cmn_location extensions, existing references and applications of this data remain unaffected.
Location migration is an ad-hoc activity that migrates existing cmn_location records to WSD table records. Ongoing feeds/ integrations that insert/update cmn_location data must be reviewed and updated accordingly to populated WSD Location tables moving forward.
Requirements:
• Family release Rome or later
• Workplace Safety Management V2.10.1 or later
Configuration:
The Location Migration feature updates the Class value of a cmn_location record based on values in the Location Type field (cmn_location_type) and parent field (parent).
Existing location hierarchies must be mapped to the WSD hierarchy. The WSD Hierarchy is: Region > Site > Campus > Building > Floor > Area (Optional) > Room/Space
Detailed steps are as below:
1.) Understand WSD table <> Location type relationship
As a WSD admin user (role needed: sn_wsd_core.admin), Navigate to Workplace Safety Management > Location Migration Configurations.
Note down the Workplace Location Tables and the related Location Type.
2.) Update Location Type in cmn_location
Navigate to the cmn_location table.
Identify existing location hierarchies to be moved over to WSD in the order: No parent > Region > Site > Campus > Building > Floor > Area (Optional) > Room/Space
Update the ‘Location Type’ field to the values corresponding to the intended target table.
Additional notes:
• The class value for all these records is cmn_location.
• The Location Type is non-empty and populated as described above.
• Space is not an available Location Type, but a choice record can be created for it as needed.
• Region is at the top of the hierarchy and has no parent.
• The existing hierarchy (No Parent) > Region > Site > Campus > Building > Floor > Area (Optional) > Room/Space must be strictly followed for the mapping to work. Note: In future releases, it will be possible to substitute the underlined part with any other existing cmn_location hierarchy. Only campus and below will need to follow a strict hierarchy.
• Area is an optional hierarchy. A Room or a Space can either have an Area as a parent (e.g., WSD Space A2), or it can be skipped and have a floor as a parent (e.g., WSD Space A2)
3.) Activate Location Migration Records
Activate (set active = true) Location Migration records in a top-down manner i.e., region, site, campus, building, floor, area, space, and room in that order.
If these records are activated out of order, you will get an error such as the one below.
4.) Run Location Migration
Click on the ‘Migrate Locations’ UI Action on the Location Migration Configurations module. This will kick off the location migration script in the background.
This script may take some time to complete depending on the volume of data being processed.
5.) Validate
Navigate to the location records and validate that the class field value is now updated.
The migration logic works top-down down. If for any reason, the record’s location type and its parent’s location type are not as defined in the Location Migration configuration, the said record and all its children will be excluded from the migration. In such a scenario, you may update the record and re-run the ‘Migrate Locations’ UI Action.
