ServiceNow Business Rule

You are a ServiceNow platform expert. The user wants to create and deploy business rules with before/after/async triggers and conditions to automate table operations.

What to check first

• Navigate to System Definition > Business Rules in your ServiceNow instance to see existing rules
• Verify your user role includes admin or business_rule_admin for rule creation
• Check the target table schema in System Definition > Tables to understand field names and types

Steps

1. Open System Definition > Business Rules and click New to create a business rule record
2. Set the Name field to a descriptive identifier (e.g., "Set incident priority on create")
3. Select the Table dropdown and choose your target table (e.g., incident, change_request)
4. Under When to run, choose the trigger type:
   • Before — runs before database insert/update (use for validation/field population)
   • After — runs after commit (use for notifications, downstream updates)
   • Async — runs asynchronously after commit (use for heavy operations)
5. Set Insert, Update, or both checkboxes depending on when the rule fires
6. In the Condition tab, build your filter conditions (e.g., Priority is empty AND Urgency is 1)
7. In the Advanced tab, write your business logic in the Script field using GlideRecord API
8. Click Submit to activate the business rule

Code

// ServiceNow Business Rule Script - Incident Priority Auto-Assignment
// Condition: Before Insert/Update | Priority is empty | Urgency = 1

// Access current record via 'current' object (built-in GlideRecord)
if (current.priority.isEmpty()) {
  // Set priority based on urgency
  if (current.urgency.getValue() === '1') {
    current.priority = '1'; // Critical
  } else if (current.urgency.getValue() === '2') {
    current.priority = '2'; // High
  } else {
    current.priority = '3'; // Medium
  }
}

// Optionally add a comment to the ticket
current.comments.setDisplayValue('Priority auto-assigned based on urgency');

// For AFTER business rules, use gs.info() or gs.warn() for logging
gs.info('Incident priority set to ' + current.priority.getDisplayValue());

// For ASYNC rules, use GlideRecord queries for downstream operations
var grChange = new GlideRecord('change_request');
grChange.addQuery('related_incident', current.sys_id);
grChange.query();
while (grChange.next()) {
  grChange.priority = current.priority;
  grChange.setWorkflow(false); // Prevent recursive business rule triggers
  grChange.update();
}

// Trigger event for external integration (optional)
gs.eventQueue('incident.priority.updated', current, current.

Note: this example was truncated in the source. See the GitHub repo for the latest full version.

Common Pitfalls

• Treating this skill as a one-shot solution — most workflows need iteration and verification
• Skipping the verification steps — you don't know it worked until you measure
• Applying this skill without understanding the underlying problem — read the related docs first

When NOT to Use This Skill

• When a simpler manual approach would take less than 10 minutes
• On critical production systems without testing in staging first
• When you don't have permission or authorization to make these changes

How to Verify It Worked

• Run the verification steps documented above
• Compare the output against your expected baseline
• Check logs for any warnings or errors — silent failures are the worst kind

Production Considerations

• Test in staging before deploying to production
• Have a rollback plan — every change should be reversible
• Monitor the affected systems for at least 24 hours after the change