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