Reclassification Field Map

13 min

The reclassification field map capabilities within Servicely allow an easily configurable table to determine the fields or otherwise when attempting to create or update one record from another record. This Table and the script library provided, provides the mechanism to easily maintain what fields or information is carried over, without having to change the scripting or buttons that trigger a reclassification. This has also been set up when someone as the appropriate application administration privileges for a certain Table, they can add and edit non scripted reclassification field maps as required. This has been used extensively out of the box to allow users to update what is required in the standard out of box use cases and functionality, however, is also open for administrators to use to set up new field maps to different combinations of new or existing entities.

Examples of out of the box usage, are mappings for conversion:

From Interaction to Incident
From Interaction to ITSM Request
From Incident to ITSM Request
From ITSM Request to Incident

Configuration

Field	Type	Example	Notes / Description
Active	Boolean	True	This determines whether or not the field map will be used when the reclassification field map is being used.
Advanced script	Boolean	N/A	This determines whether or not the script field will show and will be used upon execution
Method	Choice Copy Move	Copy	This will either make a copy of the special type of data from the target record, or remove it from the source record and move it to the new record.
Name	String	FirstContactResolved - Interaction \| ClientJournal > Incident \| ClientJournal	This is a read-only automatically generated field that has its content generated based on the fields configured. The format is as follows (when fields are not populated, it will simply be blank): <Unique Map> - <Source Table> \| <Source Field> [<Attachment is written here when this is an attachment>] > <Target Table> \| <Target Field> [<Attachment is written here when this is an attachment>]
Script	Script	N/A	Allows you to script the content going into the target field or a script that runs without inserting into a specific field. Whatever you return in the script, will go into the target field. Within the script field, you have access to the source record and source table name (accessed via sourceRec and sourceTable respectively) and the target record and target table (accessed via targetRec and targetTable respectively). In situations where you need to access a specific script library for use within the script, you will need to use the require functionality. For example: require("WorkflowUtil");. In situations where you want to populate the target field, you will remember to return a value within the script.
Source field	String	ClientJournal	The name (not label) of the field that the data will be sourced from.
Source table	Table	Interaction	The table that the data will be sourced from.
Special type	Choice Attachment HTML Journal	Journal	Required to insert data into special field types. If you do not use this for the appropriate field type, it will not be inserted into the new record correctly.
Target field	String	ClientJournal	The name (not label) of the field that the data from the source field will be inserted into.
Target table	Table	Incident	The table that the data from the source table will be inserted into.
Unique map	String	FirstContactResolved	This allows you to specify a name of a map, where as you need different fields / scripts for the same source and target table combination.

Implementing functionality

Within Servicely the reclassification field map Table is heavily used for out of box functionality to allow administrators to easily change, add and remove fields to be transferred based on a button. Examples of this are: the classify and resolve interaction buttons on interaction, creating a change, problem, ITSM request or knowledge article from Incident and updating a record when it has been considered resolved on zero contact from an interaction in the background. To use this table for a different combination of entities, there are a few steps that need to be taken. Note that for interaction it it is already largely in place for any work type, assuming you have the appropriate source table / target table. For more information on this specific use case, see the Enabling an application on interaction. To use this functionality outside of this use case, the following steps should be taken. To help illustrate each step, the example of creating an Incident from an ITSM Request will be used to highlight what steps need to be taken. This will not detail every field map record required (see out of box examples and the specific field map examples section of this page for more details), but will provide the steps required to achieve this are:

Determine what record you want to make from what record. In this case, we want to create an Incident from an ITSM request.
Determine what fields you want to set on the ITSM request from an Incident. Note that the field names do not need to be consistent across both.
Create the appropriate reclassification field map records, ensuring that the source table is the record that is being used for the source of information for the target. In this case, source table would be ITSMRequest (the name not label) and target table would be Incident.
Then set up a way to trigger the the reclassification to occur. This is commonly done via a Table operation action. Within the action when creating a new record, you need to include a script similar to below

//This will return back the ID of the new record (which you can use to direct or otherwise). 
//The other parameters are as follows:
//
//current - This is the record we are sourcing the data from.
//"Incident" - This is the source table we are creating the record from (in this case, it's going to be the same Table as current).
//"ITSMRequest" - This is the target table we are creating a record for.
 
var newRecId = ReclassificationUtil.reclassifyRecord(current, "Incident", "ITSMRequest");

When this script is run, it will get any record that has no unique map set (in this example). As an optional extra, if you add a 4th parameter to the above function, it will only get the records with that unique map.

That's it when creating a new record from a source record.

If you want to update an existing record from a different record (as done in the zero contact resolution), you need to include a script similar to below:

//The parameters used below are as follows
//
//current - This is the record we are sourcing the data from.
//"Incident" - This is the source table we are creating the record from (in this case, it's going to be the same Table as current).
//"ITSMRequest" - This is the target table we are creating a record for.
//"ZeroContactResolved" - The name of the unique map we are using
//true - This is determining whether we are updating a record vs creating it (only required when we are updating).
//newRecId - This is the ID of the target record we are updating.
 
ReclassificationUtil.reclassifyRecord(current, "Incident", "ITSMRequest", "ZeroContactResolved", true, newRecId);

Specific field map examples

The sections details a variety of different field map examples to achieve certain requirements. In addition to the below section, there are a variety of standard examples in the out of box product which can be used as an example. It should be noted that you can do quite advance scripting in the advanced script field, however, this is scarcely required. In the below examples, we are using ones when you press "resolve interaction" on an interaction when the work type is "Incident".

Copy of one field to another on the target

This is to copy one field from one to another. This will also work for singular reference fields.

Field	Example
Active	True
Advanced script	False
Method
Name	Interaction \| ShortDescription > Incident \| ShortDescription
Script
Source field	ShortDescription
Source table	Interaction
Special type
Target field	ShortDescription
Target table	Incident
Unique map	FirstContactResolved

Update the workflow status of the target record

This is used to update the status of the target record. Due to the script's evaluation scope, you need to "require" the script library that will be used. This example sets the newly created incident to resolved (running the set to resolved transition from the new status).

Field	Example
Name	FirstContactResolved - Interaction \| Advanced > Incident \| WorkflowStatus
Active	True
Unique map	FirstContactResolved
Special type
Method
Source table	Interaction
Source field
Target table	Incident
Target field	WorkflowStatus
Advanced script	True
Script	let WorkflowUtil = require("WorkflowUtil");WorkflowUtil.updateWorkflowStatusFromTransition(targetRec, "new.resolved");

Copying multiple reference field entries from one to another

This is the format used for multiple reference fields and will use the field names detailed on the relationship definition for that multiple reference field. This example uses the follower field from an interaction to the follower field on an incident.

Field	Example
Name	Interaction \| Advanced > Incident \| Advanced
Active	True
Unique map	FirstContactResolved
Special type
Method
Source table	Interaction
Source field
Target table	Incident
Target field
Advanced script	True
Script	let followerArr = sourceRec.getRelation("Follower").map(it => it.ID()); followerArr.forEach(function(follower){ Table("WorkFollower").newRecord().Work(targetRec.getID()).User(follower).create();});

Basic scripted example

The script written here can be complex or simple, depending what you need to do.

Field	Example
Name	FirstContactResolved - Interaction \| Advanced > Incident \| FirstContactResolved
Active	True
Unique map	FirstContactResolved
Special type
Method
Source table	Interaction
Source field
Target table	Incident
Target field	FirstContactResolved
Advanced script	True
Script	return true;

Copy journal entry and attachments

In this example, there are two reclassification field maps to accomplish this. If we did not include the attachment field map, the journal would copy over, but any attachments would be referring to the source record's attachment records (which the user may or may not have access to see). The first field map is for the actual journal entries and the next is for the attachments associated with the journal entry field. We do this on a per field basis for journals, to ensure only the attachments and entries that need to be copied, are copied.

Field	Example
Name	Interaction \| ClientJournal > Incident \| ClientJournal
Active	True
Unique map	FirstContactResolved
Special type	Journal
Method	Copy
Source table	Interaction
Source field	ClientJournal
Target table	Incident
Target field	ClientJournal
Advanced script
Script

Field	Example
Name	Interaction \| ClientJournal [Attachment] > Incident \| ClientJournal [Attachment]
Active	True
Unique map	FirstContactResolved
Special type	Attachment
Method	Copy
Source table	Interaction
Source field	ClientJournal
Target table	Incident
Target field	ClientJournal
Advanced script
Script