ServiceNow allows fulfillers to update RITMs including the variable editor. This helps fulfillers to correct the submitted requests instead of asking requester to raise request again.
What options we have now?
To see the changes made by the fulfillers on the variables after request was raised one can check in History Calender and History List (OOTB only available for admin).
What we are looking for?
How convenient it would be if the changes made variables are displayed on the form itself like changes made to fields? That would be great isn’t it.
Why is it required?
Before we start with the technical part I would like to list few posts asking this. I recently came across a question on ServiceNow community checking if its possible (unfortunately I am not able to find that anymore). Here are few other questions asked but I didn’t find any concrete solution on any of them.
- https://community.servicenow.com/community?id=community_question&sys_id=1701ed1adb86e740f0612183ca96...
- https://community.servicenow.com/community?id=community_question&sys_id=e99aec5ddb455b44fc5b7a9e0f96...
- https://community.servicenow.com/community?id=community_question&sys_id=66cfcf65dbdcdbc01dcaf3231f96...
- https://community.servicenow.com/community?id=community_question&sys_id=997a47e9db5cdbc01dcaf3231f96...
Technical Solutions
Now it’s time to get dirty and see how we can achieve this.
To track the changes made to variable editor we can use current.variables.changes() and then current.variables.variable_name.changes(); like we use on fields. It makes more sense to only add the variables modified with current and previous values to activity formatter like fields are when.
If you are not aware already then Journal fields could support HTML if HTML value is wrapped in [code] tag. This informs the system that the Journal field value should be treated and rendered as HTML.
For more information checkout block Formatting within Journal fields using HTML & [code] by
Option 1
Simplest option would be to track the changes made to variables and add those to work_notes (which OOTB is not used on RITM).
We need a system property to enable/disable the tracking of requested item variables in activity formatter, and a before query business rule to generate and add work_notes from the modified variable labels and their values.
System Property
Name: glide.sc.audit_log.variables
Description: Audit changes to service catalog variables in Requested Item activity formatter.
Type: true|false
Value: true
Once created add it Service Catalog category (with order 850) so that its available on Service Catalog Properties.
Business rule
Name: Add variable changes to Activity Trail
Table: Requested Item [sc_req_item]
When: before
Insert: True
Update: True
Condition: gs.getProperty("glide.sc.audit.variables.form", "false") && (current.operation() == "insert" || current.variables.changes())
Script:
(function executeRule(current, previous /*null when async*/ ) {
var isInsert = current.operation() == "insert";
var htmlString = [];
// Loop through all the variables to check the modifications
for (var i in current.variables) {
// Check if the current variable is modified
if ((isInsert && !current.variables[i].nil()) || current.variables[i].changes()) {
var variableChange = current.variables[i].getLabel() + "  ";
if (current.variables[i].nil()) {
variableChange += "[Empty]";
} else {
variableChange += current.variables[i].getDisplayValue();
}
if (!isInsert && !previous.variables[i].nil()) {
variableChange += " <em>was</em> " + previous.variables[i].getDisplayValue();
}
htmlString.push(variableChange);
}
}
if (htmlString.length > 0)
current.work_notes = "[code]" + htmlString.join("<br />") + "[/code]";
})(current, previous);
Almost there. We only have to make sure that the Work notes field is tracked under activity formatter.
Result:
Once done here is how we will see variables values on creation as well as on modifications.
When new request is raised all the non-empty variable values are captured on the ticket.
When the variables are modified by the fulfillers then modified variables with their current and previous values are captured.
Issue(s):
- In case you are using work_notes on RITM table then you might have an issues (not exactly an issue if you concatenate but isn’t clean) as fulfillers could update the variables as well as add work_notes in a single update.
- The formatting is not exactly as OOTB but it’s close to it and sufficient to understand.
Option 2 (recommended)
This option is similar to option 1 but more cleaner. We will have a property, a new Journal Input field, a business rule and three ACLs.
First of all we will create a new field of Journal Input type so we can keep the Activity Formatter more clean when it comes to variable modifications.
Create a field with name Variable changes [u_variable_changes] on sc_req_item. Please keep the label and name exactly as specified.
We will use the same property as option 1.
System Property
Name: glide.sc.audit_log.variables
Description: Audit changes to service catalog variables in Requested Item activity formatter.
Type: true|false
Value: true
Once created add it Service Catalog category (with order 850) so that its available on Service Catalog Properties.
Almost same business rule but instead of work_notes fields we will add formatted text to u_variable_changes which we just now created.
Business rule
Name: Add variable changes to Activity Trail
Table: Requested Item [sc_req_item]
When: before
Insert: True
Update: True
Condition: gs.getProperty("glide.sc.audit.variables.form", "false") && (current.operation() == "insert" || current.variables.changes())
Script:
(function executeRule(current, previous /*null when async*/ ) {
var isInsert = current.operation() == "insert";
var htmlString = [];
// Loop through all the variables to check the modifications
for (var i in current.variables) {
// Check if the current variable is modified
if ((isInsert && !current.variables[i].nil()) || current.variables[i].changes()) {
var variableChange = current.variables[i].getLabel() + "  ";
if (current.variables[i].nil()) {
variableChange += "[Empty]";
} else {
variableChange += current.variables[i].getDisplayValue();
}
if (!isInsert && !previous.variables[i].nil()) {
variableChange += " <em>was</em> " + previous.variables[i].getDisplayValue();
}
htmlString.push(variableChange);
}
}
if (htmlString.length > 0)
current.u_variable_changes = "[code]" + htmlString.join("<br />") + "[/code]";
})(current, previous);
We don’t want anybody to use this new field anywhere like list view, form and templates. To ensure this we need to add an ACLs as shown in screenshots.
Phew! We are almost to the end of this configuration. We have to make sure that the Variable changes field is tracked under activity formatter.
Click Configure available fields and add Variable changes field > click Save.
Result:
Once done here is how we will see variables values on creation as well as on modifications.
When new request is raised all the non-empty variable values are captured on the ticket. So in below image you can see that field modifications are captured as Field change and variable modifications as Variable changes.
When the variables are modified by the fulfillers then modified variables with their current and previous values are captured.
Issue(s):
- The formatting is not exactly as OOTB but it’s close to it and sufficient to understand.
Future enhancement(s)
I will keep trying to make it give the same formatting as that OOTB for Field changes. Any help with this will be highly appreciated!
Note: Multi-row variable sets are not yet supported.
5 Comments
