You are a ServiceNow developer at a large healthcare organization. You have created a custom table 'u_medical_device' to track medical equipment. The table has fields: 'u_device_id' (string), 'u_device_type' (choice: 'Monitor', 'Ventilator', 'Pump'), 'u_location' (reference to 'u_location' table), 'u_status' (choice: 'Active', 'Inactive', 'Maintenance'), and 'u_last_calibration_date' (date). You need to implement a business rule that, when a device's status is changed to 'Maintenance', automatically sets the 'u_last_calibration_date' to the current date and creates a 'u_maintenance_log' record with a reference to the device. Additionally, you want to ensure that only users with the 'medical_device_admin' role can change the status to 'Maintenance'. You have written the business rule but it is not firing correctly. The sys_script table shows the rule is active, order 100, when 'before' query and 'after' update. The condition is: current.status.changes() && current.status == 'Maintenance'. The script sets current.u_last_calibration_date = gs.now(); and creates a GlideRecord for u_maintenance_log. However, the calibration date is not updated, and no log record is created. What is the most likely cause?
Trap 1: The script uses 'gs.now()' which returns a date-time string, but…
ServiceNow automatically converts date-time strings to date when assigning to a date field. This is not the cause.
Trap 2: The user executing the update does not have the…
While role-based access is required, the business rule itself does not enforce roles; ACLs would. The rule should fire regardless of role, but the status change might be blocked by an ACL. However, the question states the rule is not firing correctly, implying the script doesn't run.
Trap 3: The condition 'current.status.changes() && current.status ==…
The condition is valid. 'changes()' returns true if the field has changed, and '==' compares the new value. This is a common pattern.
- A
The script uses 'gs.now()' which returns a date-time string, but 'u_last_calibration_date' is a date field, causing a type mismatch and silent failure.
Why wrong: ServiceNow automatically converts date-time strings to date when assigning to a date field. This is not the cause.
- B
The business rule is set to run 'before' query instead of 'before' update or 'after' update.
A 'before' query rule runs when the record is retrieved from the database, not when it is updated. For the logic to execute on update, the rule should be set to 'before' update or 'after' update.
- C
The user executing the update does not have the 'medical_device_admin' role, and the business rule lacks an ACL check.
Why wrong: While role-based access is required, the business rule itself does not enforce roles; ACLs would. The rule should fire regardless of role, but the status change might be blocked by an ACL. However, the question states the rule is not firing correctly, implying the script doesn't run.
- D
The condition 'current.status.changes() && current.status == 'Maintenance'' is invalid because 'changes()' returns a boolean and cannot be combined with '=='.
Why wrong: The condition is valid. 'changes()' returns true if the field has changed, and '==' compares the new value. This is a common pattern.