After Business Rules in ServiceNow: Scenarios and Best Practices

Overview

Business rules in ServiceNow are scripts that run on the server-side in response to record inserts, updates, deletions, and queries. They are necessary to guarantee data integrity and enforce business logic. A specific kind of business rule is known as the "After Business Rule." As the name implies, these rules take effect following a database operation, enabling you to carry out tasks that are contingent upon the outcome of the initial operation. In-depth instructions, scripts, and scenarios for efficiently utilizing After Business Rules in ServiceNow are covered in this article.

Scenarios for Using After-Business Rules

1. Situations for Applying After Business Rules Audit Logging: An audit log of modifications made to particular records should be kept on file.
   Use Case: Create an entry in a custom audit log table documenting the details of the change following the updating of a record in the Incident table.
2. Notify stakeholders when specific changes take place in this notification-triggering scenario.
   Use Case: Notify the change manager and impacted users via email when a change request is approved.
3. Scenario for Data Synchronization: Coordinate data between tables or external systems.
   Use Case: Ensure that modifications to a user record are reflected in an external HR system.
4. Cascade Updates: Relateable records are updated automatically.
   Use Case: Automatically close all child incidents following the closure of a parent incident.

Scripting After Business Rules

When scripting After Business Rules, you have access to several key objects and methods:

• current: The current record is being processed.
• previous: The record's state before the current update.
• gs: The GlideSystem object for logging messages and adding info/error messages.

1. Audit Logging

(function executeRule(current, previous /*null when async*/) {
    var auditLog = new GlideRecord('u_audit_log');
    auditLog.initialize();
    auditLog.u_table = 'incident';
    auditLog.u_record_id = current.sys_id;
    auditLog.u_changed_by = gs.getUserID();
    auditLog.u_change_description = 'Incident updated';
    auditLog.insert();
})(current, previous);

2. Notification Triggering

(function executeRule(current, previous /*null when async*/) {
    if (current.state == 'approved' && previous.state != 'approved') {
        var gr = new GlideRecord('sys_email');
        gr.initialize();
        gr.type = 'send-ready';
        gr.recipients = current.change_manager.email;
        gr.subject = 'Change Request Approved';
        gr.body = 'Change request ' + current.number + ' has been approved.';
        gr.insert();
    }
})(current, previous);

3. Data Synchronization

(function executeRule(current, previous /*null when async*/) {
    var hrSysId = current.u_hr_sys_id;
    if (hrSysId) {
        var hrRecord = new GlideRecord('u_hr_table');
        if (hrRecord.get(hrSysId)) {
            hrRecord.u_name = current.name;
            hrRecord.u_email = current.email;
            hrRecord.update();
        }
    }
})(current, previous);

4. Cascade Updates

(function executeRule(current, previous /*null when async*/) {
    if (current.state == 'closed' && previous.state != 'closed') {
        var childIncidents = new GlideRecord('incident');
        childIncidents.addQuery('parent', current.sys_id);
        childIncidents.query();
        while (childIncidents.next()) {
            childIncidents.state = 'closed';
            childIncidents.update();
        }
    }
})(current, previous);

Best Practices for After Business Rules

1. Minimize the Performance Impacts

   • Avoid complex calculations and excessive queries within business rules to prevent performance degradation.
   • Use asynchronous business rules when the action doesn't need to be performed immediately.

2. Avoid Conflicting Rules

   • Make sure that multiple business rules do not conflict with each other, leading to unintended behavior.
   • Test thoroughly to identify and resolve any conflicts.

3. Use Conditions Wisely

   • Use conditions to limit the execution of business rules only when necessary. This reduces unnecessary processing.

4. Document Your Rules

   • Clearly document the purpose and functionality of each business rule. This aids in maintenance and troubleshooting.

5. Error Handling

   • Implement proper error handling to manage any issues that arise during the execution of your business rules.
   • Use gs.addErrorMessage to inform users of any critical errors.

6. Security Considerations

   • Ensure that business rules do not expose sensitive information or perform unauthorized actions.
   • Use GlideRecordSecure instead of GlideRecord when necessary to enforce ACLs.

Summary

ServiceNow's After Business Rules are effective instruments for guaranteeing data integrity, automating processes, and upholding business logic. Through comprehension of scenarios, efficient scripting, and adherence to recommended practices, you can fully utilize After Business Rules to improve your ServiceNow implementations. A more reliable ServiceNow environment and more effective procedures will result from the proper application of these guidelines. Happy learning until next time.