Why Require Work Notes, When Resolving/Closing an Incident?
This requirement should be default in all ServiceNow instances.
Especially for P1/P2 incidents.
You’ll see this request come in from IT managers, because it enriches a companies IT data. When looking back on thousands of incidents, you’re able to get a “full picture” of what happened and why a fulfiller felt comfortable resolving any particular incident.
Fulfillers even forget why they did something at a certain time, so it’s even good for them to jot down a quick note on an incident, so they don’t forget.
Every company is a little different, and I’m sure many companies would push back on this requirement.
There are a few reasons why you might want to require a work note to be added to an incident before it can be resolved:
- Documentation: A work note can provide a record of the actions taken to resolve an incident. This can be helpful for future reference or for audits.
- Communication: A work note can help communicate the resolution of an incident to other team members, stakeholders, or customers.
- Problem-solving: By requiring a work note to be added before resolving an incident, you can ensure that the root cause of the incident is identified and documented. This can help prevent similar incidents from occurring in the future.
- Compliance: Depending on the industry or regulatory environment, there may be requirements to document certain types of work or actions taken. A work note can help ensure that these requirements are met.
These are just a few of the reasons that we’re able to come up with.
Let us know if you think there are more reasons to require a work note, before resolving an incident.
How To Write The Business Rule
As expected, the ‘admin’ role is required to create a business rule.
The business rule needs to be before = true and update = true.
Make sure it’s on the incident table, too.
Below in the condition, the default value for “Resolved” on the incident table for the state field, is 6, so if this has been modified – you’ll need to modify the condition of the script.
Condition:
current.state.changesTo(6) && current.work_notes == ''
Script:
(function executeRule(current, previous /*null when async*/) {
// Check if the incident has a work note
if (!current.work_notes) {
// If the incident does not have a work note, set an error message
current.addErrorMessage('A work note is required before resolving this incident');
}
})(current, previous);
That’s it, let’s go ahead and test this business rule.
Test The Business Rule
To test the business rule, go and close any incident, but don’t add work notes.
If you followed the above properly, you will see the following error when you save the incident.
The incident will not save the requested update and you’ll see the above error.
That’s it.
Feel free to take the above script and modify it to your requirements.
Be aware that end users are likely to complain about this, because it is a nuisance to do, especially when you’re working in incidents all day. It can be a tough feature to get used to.
Let us know if you have any questions below in the comments of this article.
