Error Reference

Recursion detected: business rule triggered itself

Recursion detected: business rule triggered itself

Where this appears

This error appears in the System Log at System Diagnostics > Log > Application Log when a business rule creates an infinite loop. The error occurs during record operations like insert, update, or delete when ServiceNow's recursion detection prevents a stack overflow by stopping the loop after detecting the same business rule triggering repeatedly.

Sourdough
Chrome Extension

Debugging this in a real instance?

Sourdough lets you trace "Recursion detected: business rule triggered itself" through system logs, script errors, and API health in the ServiceNow tab you are already using.

Add to Chrome

Free to install. Pro $5/month after a 14-day no-card trial.
Pro requires the ServiceNow admin role. Upgrade inside the extension.

Overview
Tasks
CMDB
API
Metrics
Monitor
Internals
Instance:sourdoughdev·Version:Yokohama
Instance StateONLINE
System StatusFully Operational
Session Timeout90 minutes
Logged-In Sessions2 (20 active)
Build Nameyokohama-12-18-2024_p1
IP Address10.159.128.43
Instance HealthHealth Score: 90%
🔥 5dSourdough (Chrome Plugin)Dark Mode

Cause

A before/after business rule modifies the same field or related record that triggers the same business rule to execute again, creating an infinite loop. (high likelihood)

Multiple business rules are triggering each other in a circular pattern, where Rule A triggers Rule B, which triggers Rule A again. (high likelihood)

A business rule calls gr.update() or gr.insert() on the current record or a related record that has the same business rule conditions, causing re-execution. (medium likelihood)

A business rule uses setValue() on a field that is also being modified by the same business rule in different execution paths or conditions. (medium likelihood)

Workflow or other automation triggered by the business rule is updating fields that cause the same business rule to fire again. (low likelihood)

Fix

Step 1: Navigate to System Diagnostics > Log > Application Log and search for the exact error message to identify which business rule and table are involved in the recursion.

Step 2: Go to System Definition > Business Rules and locate the problematic business rule mentioned in the error log, noting its conditions, when to run settings, and script content.

Step 3: Review the business rule script to identify any gr.update(), gr.insert(), current.update(), or setValue() calls that modify fields matching the business rule's condition or when-to-run criteria.

Step 4: Add a recursion prevention mechanism by creating a custom field or using current.setWorkflow(false) before making updates, or check if the rule has already executed using current.isValidField() or a flag variable.

Step 5: If the business rule must modify triggering fields, change the When setting from 'before' to 'after' if possible, or split the logic into separate business rules with different conditions.

Step 6: Test the fix by performing the same operation that caused the original error and monitor the System Log to ensure the recursion no longer occurs.

Step 7: Review related business rules on the same table to identify potential circular dependencies and adjust their conditions or execution timing if necessary.

Test Your Knowledge

Quick 3-question quiz. See how your ServiceNow skills stack up.

Question 1 of 3Performance

A list view on a table with millions of records is slow. Best fix?

Select an answer to continue