Disabling Business Rules and Workflows During Scripted Updates - ben-vargas/servicenow-wiki GitHub Wiki

    // Disable workflow/business rules and automatic system field updates
    current.setWorkflow(false);
    current.autoSysFields(false);

When interacting with ServiceNow records through server-side scripting, there are instances where you may need to prevent certain platform automation—such as business rules, workflows, and system field updates—from running. This can be useful for data migrations, bulk updates, or performance-sensitive operations.

This guide provides an overview of how to temporarily disable these behaviors and highlights best practices to ensure a smooth and controlled update process.

Key Scenarios:

• Data Migrations & Bulk Updates: Running a large volume of updates without business rules and workflows can drastically improve performance.
• Controlled Changes: Certain scripts may run specialized logic that you don’t want overridden or complicated by existing automations.
• Avoiding Side Effects: Prevent unintended notifications, task assignments, or record duplications triggered by active workflows or onUpdate business rules.

When working with a GlideRecord in a script, you can leverage built-in methods to control the execution of workflows, business rules, and automatic system field updates.

Usage:
<GlideRecordVariable>.setWorkflow(false);

By default, updating a record triggers workflow activities and business rules set to run on insert/update events. Using setWorkflow(false) instructs ServiceNow to not run business rules and workflows for the current operation.

Example:

var incidentGR = new GlideRecord('incident');
incidentGR.get('some_incident_sys_id');

// Disable workflows and business rules for this update
incidentGR.setWorkflow(false);

incidentGR.short_description = "Bulk updated via script";
incidentGR.update();

In this example, the updated incident record will not trigger any workflows, business rules, or notifications normally associated with an update action.

Usage:
<GlideRecordVariable>.autoSysFields(false);

By default, ServiceNow automatically updates system fields such as sys_created_by, sys_created_on, sys_updated_by, and sys_updated_on whenever a record is inserted or updated. Using autoSysFields(false) prevents automatic updates to these system fields, preserving the original metadata.

Example:

var incidentGR = new GlideRecord('incident');
incidentGR.get('some_incident_sys_id');

// Disable automatic system field updates
incidentGR.autoSysFields(false);

incidentGR.description = "This update does not change sys_updated_on";
incidentGR.update();

With autoSysFields(false), the sys_updated_on and sys_updated_by fields remain unchanged after the update.

It’s common to use setWorkflow(false) and autoSysFields(false) together when performing bulk updates or data migrations, allowing maximum control over what is changed and logged by the platform.

Example:

var incidentGR = new GlideRecord('incident');
incidentGR.addQuery('state', 1); // e.g., query all new incidents
incidentGR.query();

while (incidentGR.next()) {
    // Disable workflow/business rules and automatic system field updates
    incidentGR.setWorkflow(false);
    incidentGR.autoSysFields(false);

    incidentGR.state = 2; // Set state to "In Progress"
    incidentGR.update();
}

What Happens Here?

• No business rules or workflows trigger upon each update.
• System fields like sys_updated_on and sys_updated_by remain unchanged.
• This approach ensures consistent metadata retention and avoids unwanted automation.

1. Use Sparingly:
   Disabling workflows, business rules, and system field updates should be done carefully. These mechanisms exist to maintain data integrity, enforce processes, and log changes. Only disable them when you fully understand the implications.

2. Document Your Changes:
   If you run scripts that disable these features, keep a record of why and when you did so. This helps with auditability and future maintenance.

3. Test in Non-Production Environments:
   Always test changes in a sandbox or development environment to ensure that disabling these automations does not produce unintended data inconsistencies.

4. Re-Enable When Necessary:
   If you need to perform subsequent updates that do require business rules or workflows, make sure to remove or comment out the disabling lines of code.

5. Version & Backup Data Before Mass Changes:
   Especially for large-scale operations, consider backing up data or having a rollback plan. Without workflows and business rules, changes may be harder to trace and revert.

• ServiceNow Documentation:

  • GlideRecord API Reference for detailed API usage.

• ServiceNow Community:

  • ServiceNow Community Forums to discuss approaches and best practices with other developers.

By using setWorkflow(false) and autoSysFields(false), developers gain granular control over how records are updated in ServiceNow. Whether performing bulk data migrations, safeguarding against unwanted triggers, or maintaining historical accuracy in system fields, these methods ensure that you can carefully tailor your update behavior to meet specific operational needs.

Use these techniques responsibly, document your changes, and enjoy improved performance and flexibility when you need it.