Journal Entry Migration

This article provides more detailed information on how the Journal Entry Migrator Virtual Table works.

This is available as a target table for all migrations and is used to populate the journal records in ServiceNow so that the activities are presented with the correct username and timestamp.

The #!JOURNAL ENTRY MIGRATOR!# virtual table does 3 things:

1. Creates a single journal entry, based on the values passed into the virtual table (see below)
2. Creates the audit record associated with the journal entry addition (if required). The audit record is required for the journal entry to show in an activity log in service now.
3. Refreshes the history (basically by deleting the sys_history_set record for this ticket). This will be required if the record has been previously viewed in ServiceNow, since the history records are what actually form the entries in the activity log. OTB, when a user adds a journal entry, the history will automatically get updated so they will see it in the activity log. By deleting the history set, you can force SN to regenerate it next time the record is viewed and pick up any audit records added via PB.

Typically, in a BMC Remedy -> SN migration, the journal entries will come from worklog entries in Remedy. Other source platforms will usually have a table storing notes, comments or worknotes.

The fields should be set as follows:

• Add Audit Entry. Set to True if you want an audit entry created. Typically you will always need one if the journal entry is to be viewed in an activity log.
• Created By. Set to the User who created the source worklog. This does not need to be an existing user in SN, so you can just map the created By user on the source.
• Created On. Set to the Timestamp the source entry was created on. It is important that this gets set, since the activity log displays in order of created date.
• Disable History Refresh. Set to False (usually). Typically you would only want to disable this if you are adding additional audit records later in the migration, and will then have a further mapping to refresh the history after this.
• Journal Entry Text. The text you want displayed in the worknote. Map to the appropriate field in the worklog
• Field Name. The name of the Journal Entry field on the target form to which the journal entry is associated. For most tickets, this will be either comment or work_note. Comments are customer visible, work_notes are not. For Remedy source, you can use a value mapping to set this according to whether the source work log entry is customer visible or internal.
• Parent ID. The sys_id of the parent record. If you have a field on both the source and target record that is unique, e.g. the ticket number you can use a target lookup to get this sys_id, with a query something like this: [number] = #SRC.Incident Number#. Alternatively, if you are migrating the parent tickets earlier in the migration, you could use a reference mapping to set this.
• Parent Table. The name of the table in service now that the journal entry will be displayed on. E.g sn_customerservice_case for the Case Table.

For the Journal entries to display in the activity log correctly, they must all have a timestamp later than the date the parent ticket was created. If not, the activity records may display with the incorrect timestamp and incorrect ordering. Or possibly not display at all. Therefore you must map the created field on the SN parent record to the created on field in the source parent record to ensure no journal entries exist that have a created timestamp earlier than the timestamp that the ticket was created.