Archiving Service Now Attachments to File or AWS

Overview

This article details how to construct a migration project for the very specific use case of moving ServiceNow attachments to off-server storage. This is sometimes required to reduce storage requirements for the ServiceNow instance, and therefore costs.

This migration is somewhat different to most in that the data records themselves are not moved - only the attachments.

Precision Bridge will need to be configured to:

1. Identify the ServiceNow attachments that are to be archived.
2. Extract these attachments and move them to the storage location.
3. Create a (Linked File) record on the ServiceNow server detailing where each attachment is located in storage (to ensure the attachments are still linked to the data records in some way and can be retrieved if needed)
4. Delete the attachment in ServiceNow, checking first that it has been migrated successfully.

Creating the Project

Unlike most projects, the source and target server will be the same. The source server will be where the attachments are to be retrieved from and the target server will be where the Linked File record will be written to.

Adding the Form Mapping

Once the project is open, Create a Form Mapping for the table Attachment (sys_attachment) and set the following:

• On the Field Mappings tab, map only the Sys ID field using a simple mapping
• On the Key Mappings tab select the 'Select Key Mappings' option and then add the Sys ID mapping.
• On the Options tab, set the Attachment migration option to 'all attachments'
• On the Source Deletions tab, check 'Delete Source Attachmentsaftre Migration'. Set the 'Action if Unmigrated Attachments Exist' to 'Do Not Delete Source Record'. All cascade delete table actions should be set to 'Delete Source Record'. See screenshot below
• On the Source Filtering tab, you must define the set of attachments you want to archive. Typically, you might want to archive all attachments for a given set of records (eg incidents) however the full range of filtering options is available to you. See the Source Filtering section for more details. Assuming you want to archive attachments for a set of incidents, in the Filter by Inclusion section, select the value set definition method to 'Source Adhoc query'. Then select:
  • Source field = Table Sys ID
  • Value Set Form = the parent table for the attachments you are archiving (e.g Incident)
  • Value set Field = Sys ID
  • The Value Set Query should identify the set of incidents you want to archive attachments for. For example for a single, numbered incident you might use: [number] = 'INC0011617'

Showing the recommended Source Deletion settings

Showing example source filtering that will migrate all attachments for a single incident.

Executing the Project.

WARNING: This project will delete the source attachment after successful archiving. Always test executions in a non-production environment first - particularly after making changes to the source filtering.

In the execution options, as displayed when you initiate an execution, you will need to re-direct attachments to either File storage or an AWS bucket. This is set on the Attachments tab, within the define attachment target sub-tab. Note that to use AWS, you will need to configure this for use with Precision Bridge - see this article for details: Defining Attachment Options

The example below shows the attachments being moved to an AWS bucket named tkbucket-test.

Remember to save the execution settings after making this change (they will also be saved if you schedule the execution of the project)

Checking the Results

It is advised to test with a small number of attachments first.

For File system migration:

• The attachment files will be written to: <root directory>\<table name>\<parent record sys id>_<attachment_sys_id>_<filename>
• An entry will be created in the Linked Files (u_pb_linked_files) table containing the sys_id of the incident and the full file path to the attachment.

For AWS migration:

• The attachment files will be written to: <aws bucket>\<table name>\<parent record sys id>_<attachment_sys_id>_<filename>
• An entry will be created in the Linked Files (u_pb_linked_files) table containing the sys_id of the incident and the s3 path to the attachment.

Access to AWS attachments from ServiceNow

It should be be noted that the URL given in the Linked Files record for the attachment does not provide a clickable URL to the file, it is the S3 URL for the file. It would be possible to add a second mapping to the Precision Bridge project to transform this value into a the URL for the file, however for this URL to work correctly from a browser, the object needs to be set as public, and all files should be added as private by default.

The S3 URL does include the full file path, which can be used to find the object using a prefix search in the S3 bucket itself.