Business Rules
Validate Planned Change Dates
Prevent a change request from saving when its planned end is before its planned start, using server-side validation rather than a form-only check.
(function executeRule(current, previous) {
var start = current.getValue('start_date');
var end = current.getValue('end_date');
if (!start || !end) return;
try {
if (new GlideDateTime(end).compareTo(new GlideDateTime(start)) < 0) {
gs.addErrorMessage('Planned end must be on or after planned start.');
current.setAbortAction(true);
}
} catch (error) {
gs.error('[Change:PlannedDateValidation] ' + error.message);
gs.addErrorMessage('Unable to validate planned dates. Contact your administrator.');
current.setAbortAction(true);
}
})(current, previous);How to use it
1. In a sub-production instance, first check existing Change Management date validation. Use this custom example only if equivalent server-side validation is absent; do not duplicate an out-of-box rule. 2. Create an Advanced Business Rule on Change Request [change_request], in the same scope as the table (normally Global). Select Before, Insert and Update; leave Delete and Query unchecked. Use order 100 and no filter condition to check every save. Review ordering if other rules modify planned dates. 3. Paste the script. It reads Planned start date [start_date] and Planned end date [end_date] as internal date/time values, avoiding display-format and user-time-zone parsing. It does not call current.update(). 4. Empty dates are intentionally allowed: enforce required dates separately with the applicable Data Policy. Equal start/end values are allowed. Existing reversed ranges will block unrelated updates until corrected. 5. Test insert and update with end before start (save blocked), end after start (save allowed), equal dates (allowed), and either date empty (left to mandatory-field policies). Repeat with different user time zones and REST writes that run business rules. Confirm failed saves did not persist. 6. Imports or scripts that disable business rules can bypass this check. This is date ordering only, not a maintenance-window or schedule-conflict check. Validate in ServiceNow before production use. 7. Capture the Business Rule in a dedicated update set. Roll back by deactivating the custom rule; it performs no bulk updates or data migration.
Adapt the table names, fields, and conditions to your instance. Test the behavior in a development environment before using it in production.