How to Prevent Infinite Loops in Your Business Rules

Complete Guide to Circular Reference Protection

Introduction

You've just created a business rule in Microsoft Dynamics 365 Business Central that automatically updates discount percentages when salespeople change order quantities. Feeling confident, you test it on a sales order. You change the quantity from 10 to 100, press Tab... and Business Central freezes.

The loading spinner spins. And spins. After 30 seconds, you get an error: "The operation could not be completed within the time limit."

You try again. Same result. You check the validation log—your rule executed 847 times in 5 seconds. Your heart sinks. You've created an infinite loop, and now other users are calling to say their Business Central screens are frozen too.

This scenario happens to nearly every rule builder at some point, and it's one of the most terrifying experiences in rule development. One innocent-looking rule creates a circular reference that brings down your entire Business Central system, freezes databases, and forces emergency restarts.

The good news? Once you understand what causes circular references and how to prevent them, you'll never create another infinite loop again.

This guide takes you through everything you need to know about circular reference protection: what they are, how to recognize the dangerous patterns, how to implement foolproof protection, and how to fix loops if they occur.

What we'll cover:

✓ Understanding circular references - What they are and why they happen
✓ The #1 dangerous pattern - After Modify + Assign (causes 80% of loops)
✓ Five common scenarios - Real examples of how loops occur
✓ Detection techniques - Spotting loops before they crash your system
✓ Prevention Strategy #1 - Use Before triggers instead of After triggers
✓ Prevention Strategy #2 - The flag field pattern (most reliable)
✓ Prevention Strategy #3 - Change-detection scenarios
✓ Step-by-step implementation - Add loop protection to existing rules
✓ Real-world examples - Credit limit adjustment, cascading updates
✓ Troubleshooting guide - Fix existing circular references
✓ Testing checklist - Verify your rules won't loop before deployment

Time required: 45 minutes (reading and implementation)
Difficulty: Intermediate
Prerequisites:

• Microsoft Dynamics 365 Business Central with QUALIA Rule Engine installed

• Understanding of trigger events (Before Insert, After Modify, etc.)

• Experience creating rules with Assign actions

• Access to Business Rule Sets page in Business Central

Let's make sure your rules never create another infinite loop.

Part 1: Understanding Circular References (10 minutes)

What Exactly is a Circular Reference?

Let's start with a simple analogy that makes this crystal clear.

Imagine two employees: Alice and Bob

• Alice's job: "Whenever Bob updates his spreadsheet, I update mine"

• Bob's job: "Whenever Alice updates her spreadsheet, I update mine"

What happens?

1. Alice updates her spreadsheet

2. Bob sees the change and updates his spreadsheet

3. Alice sees Bob's change and updates her spreadsheet

4. Bob sees Alice's change and updates his spreadsheet

5. Alice sees Bob's change and updates her spreadsheet

6. This continues forever until someone unplugs the computers

That's a circular reference. Each person's action triggers the other person's action, creating an endless loop.

How This Happens in Business Rules

In QUALIA Rule Engine, the exact same pattern happens when a rule's action causes that same rule (or another rule) to trigger again.

Here's a real example that causes an infinite loop:

Rule Set: SALES-LINE-DISCOUNT-AUTO
Trigger Table: Sales Line (37)
Trigger Type: After Modify

Rule: Set Bulk Discount
  Condition: [37:15] is >50  // Quantity > 50
  Action: Assign
    Field: [37:27]

Looks innocent, right? But watch what happens:

Step 1: User changes quantity to 100
        ↓
Step 2: After Modify trigger fires (quantity was modified)
        ↓
Step 3: Rule checks: Is quantity > 50? YES (100 > 50)
        ↓
Step 4: Rule executes Assign action: Set discount = 10
        ↓
Step 5: Discount field changes, so record is MODIFIED
        ↓
Step 6: After Modify trigger fires AGAIN (discount was modified)
        ↓
Step 7: Rule checks: Is quantity > 50? YES (still 100)
        ↓
Step 8: Rule executes Assign action: Set discount = 10 (already 10, but still modifies)
        ↓
Step 9: Discount field "changes", so record is MODIFIED AGAIN
        ↓
Step 10: After Modify trigger fires AGAIN
         ↓
        [INFINITE LOOP - continues until timeout/crash]

The problem: The rule's own action (Assign) causes the same event (After Modify) that triggered the rule in the first place.

Why This is So Dangerous

For your system:

• Each loop iteration consumes CPU cycles

• Database connections pile up

• Memory usage grows exponentially

• Business Central server becomes unresponsive

• Eventually crashes or forces timeout

For your users:

• Microsoft Dynamics 365 Business Central freezes completely

• Loading spinners that never stop

• Cryptic timeout error messages

• Work is lost (unsaved changes disappear)

• Other users affected simultaneously (system-wide problem)

• Users lose confidence in the system

For you:

• Emergency response required

• System restart may be needed

• All users impacted simultaneously

• Data integrity concerns (partially saved records)

• Management escalation

• Trust damage with users

I've seen this happen in production Business Central environments where a single circular reference brought down the entire system for 50+ users, requiring emergency intervention on a Friday afternoon. It's not fun.

The #1 Most Dangerous Pattern

80% of circular references come from this exact pattern:

Why is this so dangerous?

• After Modify means the rule runs AFTER the record is already saved

• When the rule uses Assign to modify a field, it saves the record AGAIN

• This triggers After Modify AGAIN

• The loop begins

Visual representation:

User modifies record
    ↓
[Record is saved]
    ↓
After Modify trigger fires ← Start of loop
    ↓                         ↑
Rule evaluates conditions     |
    ↓                         |
Rule executes Assign action   |
    ↓                         |
[Record is saved AGAIN] ------┘
    ↓
After Modify trigger fires
    ↓
[Loop continues forever]

Key insight: Every time you see a rule with "After Modify" trigger and "Assign" action that modifies the same table, a red alert should go off in your head: "This could be a circular reference!"

Part 2: The Five Most Common Circular Reference Scenarios (5 minutes)

Knowing these patterns helps you recognize circular references before they happen.

Scenario 1: Self-Modifying Rules (Most Common)

The rule modifies the same record that triggered it.

Example: Automatic Status Update

Rule Set: SALES-LINE-STATUS
Trigger: Sales Line (37) - After Modify

Rule: Mark as Bulk Order
  Condition: [37:15] is >100  // Quantity > 100
  Action: Assign
    Field: [37:50000]

Why this happens: The Assign action modifies the same record that triggered the rule.

Scenario 2: Cross-Table Circular References

Two rules on different tables modify each other's trigger tables.

Example: Sales Header ↔ Sales Line Synchronization

Rule A: Update Header Total
Trigger: Sales Line (37) - After Modify
Action: Modify Sales Header [36:CustomCalculatedTotal]

Rule B: Update All Lines
Trigger: Sales Header (36) - After Modify
Action: Modify all Sales Lines [37:CustomHeaderValue]

Why this happens: The two rules create a ping-pong effect, each triggering the other.

Scenario 3: Competing Rules on Same Table

Multiple rules on the same table fight over field values.

Example: Multiple Discount Rules

Rule 1: Volume Discount
Trigger: Sales Line (37) - After Modify
Condition: [37:15] is >50  // Qty > 50
Action: Assign [37:27] = 10  // Set discount to 10%

Rule 2: VIP Customer Discount
Trigger: Sales Line (37) - After Modify
Condition: [18:50000] is true  // Customer is VIP
Action: Assign [37:27]

Why this happens: Both rules are trying to control the same field, and each one's action triggers the other rule.

Scenario 4: Change-Detection Loop

Rules that detect changes and then make changes can loop.

Example: Price Change Reverter

Rule: Prevent Large Price Increases
Trigger: Item (27) - After Modify
Scenario: {27:18} is <>[27:18]  // Price changed
Condition: [27:18] is >{[27:18] * 1.10}  // Increased > 10%
Action: Assign [27:18]

Why this happens: Resetting to the old value still causes a modification event.

Scenario 5: Cascade Modification Loops

Long chains of rules can create complex loops.

Example: Three-Table Cascade

Rule A: Sales Line → Item
Trigger: Sales Line (37) - After Modify
Action: Modify Item [27:CustomLastSoldDate]

Rule B: Item → Vendor
Trigger: Item (27) - After Modify
Action: Modify Vendor [23:CustomItemsSupplied]

Why this happens: The cascade of modifications eventually circles back to the original table.

Part 3: How to Detect Circular References Before They Break Your System (5 minutes)

Detection Strategy 1: Enable Detailed Logging

Before testing any rule with After Modify + Assign, enable logging:

Steps:

1. Search for "Business Rule Setup"

2. Open the setup card

3. Find the field "Enable Validation Log"

4. Check the box (Enable = Yes)

5. Set "Log Level" to "Detailed"

6. Close the page

What this does: Logs every rule execution, showing you exactly how many times each rule runs.

How to check for loops:

1. After testing your rule, search for "Validation Log"

2. Open the log page

3. Filter by Date = TODAY and Time = recent

4. Look for the same rule code appearing many times in quick succession

Example of loop in log:

What to look for:

• Same rule executing more than 5 times for same record = red flag

• Execution times less than 50ms apart = loop likely

• Hundreds of log entries in seconds = definitely a loop

Detection Strategy 2: Test in Sandbox First

Never test After Modify + Assign rules in production without sandbox testing.

Test procedure:

1. Create the rule in your sandbox environment

2. Enable validation logging

3. Perform a simple test transaction

4. Wait 10 seconds

5. Check validation log for loop indicators

6. If log shows 1-3 executions = OK

7. If log shows 10+ executions = Loop detected, fix before production

Detection Strategy 3: Monitor Performance

Watch for these symptoms during testing:

Symptoms of circular references:

• Transaction takes longer than 5 seconds

• "Thinking" spinner spins indefinitely

• Eventually timeout error appears

• CPU usage spikes to 100%

• Database queries pile up

• Multiple users affected simultaneously

Normal behavior:

• Transaction completes in under 1 second

• No timeout errors

• Smooth, responsive interface

If you see symptoms: Stop immediately, disable the rule, check the validation log.

Part 4: Prevention Strategy #1 - Use Before Triggers Instead of After Triggers (5 minutes)

This is the simplest and most effective prevention technique.

Why Before Triggers Don't Loop

Before Insert/Modify triggers:

• Run BEFORE the record is saved

• Assign actions modify the record in-memory

• Record is saved ONCE after rule completes

• No additional trigger event fires

• Cannot create loops

After Insert/Modify triggers:

• Run AFTER the record is already saved

• Assign actions save the record AGAIN

• This fires another After trigger

• Can create loops

The Fix: Change After to Before

Original (Loop Risk):

Rule Set: SALES-LINE-DISCOUNT
Trigger: Sales Line (37) - After Modify

Rule: Set Bulk Discount
  Condition: [37:15] is >50
  Action: Assign [37:27]

Fixed (No Loop Risk):

Rule Set: SALES-LINE-DISCOUNT
Trigger: Sales Line (37) - Before Modify

Rule: Set Bulk Discount
  Condition: [37:15] is >50
  Action: Assign [37:27]

How to change the trigger:

1. Open your rule set

2. Find "Trigger Type" field

3. Change from "After Modify" to "Before Modify"

4. Save

5. Test again

When to use Before triggers:

• ✓ When assigning field values in the trigger table

• ✓ When calculating derived fields

• ✓ When defaulting field values

• ✓ When validating and correcting data before save

When you MUST use After triggers:

• Sending emails (record must be saved first)

• Inserting related records (parent record needs to exist)

• Modifying other tables (trigger record must be saved)

• Calling external APIs (only after successful save)

Quick Win: Audit Your Existing Rules

Spend 5 minutes doing this right now:

1. Open Business Rule Sets list

2. Filter by Trigger Type = "After Modify"

3. For each rule set, check if it has Assign actions

4. If yes, ask: "Does this Assign modify the trigger table?"

5. If yes, ask: "Can I change this to Before Modify?"

6. If yes, change it immediately

This simple audit can prevent 80% of potential circular references.

Part 5: Prevention Strategy #2 - The Flag Field Pattern (Most Reliable) (15 minutes)

When you absolutely must use After Modify triggers with Assign actions, the flag field pattern is your bulletproof protection.

How the Flag Field Pattern Works

The concept:

1. Add a boolean field to your table: "Processing Flag"

2. Before rule logic executes: Set flag = TRUE

3. Rule checks flag: If flag is TRUE, skip execution (exit immediately)

4. After rule completes: Set flag = FALSE

Why this prevents loops:

• First execution: Flag is FALSE, rule runs, sets flag = TRUE

• Rule modifies record, triggers After Modify again

• Second execution: Flag is TRUE, rule sees it and exits immediately

• No third execution occurs

• Loop is broken

Step-by-Step: Implementing Flag Field Protection

Let's protect a real rule that has loop risk.

Starting rule (HAS LOOP RISK):

Rule Set: SALES-BULK-DISCOUNT
Trigger: Sales Line (37) - After Modify

Rule: Calculate Bulk Discount
  Condition: [37:15] is >=100
  Action: Assign [37:27]

Step 1: Add Flag Field to Table (Requires Developer)

You'll need a developer to add this custom field:

Field requirements:

• Boolean type (true/false)

• Not editable by users

• Not visible on pages (hidden field)

• Use consistent naming (I recommend "QUA Processing Flag")

Time estimate: 10 minutes for developer to add field

Alternative: If you already have a suitable boolean field, you can reuse it. Just make sure it's not used for other business logic.

Step 2: Add Flag Check Scenario

Open your rule set and add a scenario that checks the flag:

1. Go to Business Rule Sets

2. Open your rule set (SALES-BULK-DISCOUNT)

3. Find the Scenarios section

4. Add a new scenario line:

Scenario Formula: [37:50000] is false Description: Processing flag is not set (prevents loops) Enable: ☑ (checked)

What this does: If the flag is TRUE, the scenario fails, and the entire rule set is skipped. Loop is prevented.

Step 3: Set Flag Before Modification

Modify your rule to set the flag first:

1. Open your rule (Calculate Bulk Discount)

2. You'll add THREE actions now (instead of one)

3. Action execution order matters—set the Order field correctly

Action 1 (Order: 1) - Set Flag:

• Type: Assign

• Field: [37:50000] // QUA Processing Flag

• Value: true

• Order: 1

Action 2 (Order: 2) - Your Business Logic:

• Type: Assign

• Field: [37:27] // Line Discount %

• Value: 15

• Order: 2

Action 3 (Order: 3) - Clear Flag:

• Type: Assign

• Field: [37:50000] // QUA Processing Flag

• Value: false

• Order: 3

What you're creating:

Rule: Calculate Bulk Discount
  Condition: [37:15]

Step 4: Test the Protected Rule

Test to verify loop protection works:

1. Enable validation logging (if not already enabled)

2. Create a sales order line with quantity = 150

3. Save the line

4. Check validation log

Expected log entries:

What happened:

1. User saved line with qty 150

2. After Modify triggered rule (first time)

3. Scenario checked flag (false) → passed

4. Rule executed

5. Action 1 set flag = true

6. Action 2 set discount = 15 (modified record)

7. Action 3 set flag = false

8. Record saved → After Modify triggered rule (second time)

9. Scenario checked flag... wait, was it true or false?

Important: In the second trigger, flag will be FALSE (because Action 3 reset it). So why doesn't it loop?

The trick: By the time the second trigger fires, all three actions have already executed in sequence, including Action 3 that resets the flag. So the flag is back to FALSE, but the discount is already set to the desired value (15). When the rule checks the condition again ([37:15] >= 100), it's still true, but the Action 2 (Set discount = 15) doesn't actually CHANGE anything (it's already 15), so no additional modification occurs.

Wait, that still sounds like it could loop!

You're right to question this. Let me clarify with a better flag pattern...

Step 4 (Revised): Enhanced Flag Pattern with Additional Protection

Add a second scenario for change detection:

1. Keep the flag check scenario: [37:50000] is false

2. Add another scenario: {37:15} is <>[37:15] // Quantity actually changed

What this does: Rule only runs if (1) flag is false AND (2) quantity actually changed.

Now the execution flow:

1. User changes quantity from 10 to 150

2. After Modify triggers

3. Scenario 1: Flag is false ✓

4. Scenario 2: Quantity changed (10 → 150) ✓

5. Rule executes three actions (flag=true, discount=15, flag=false)

6. Record is modified (discount field changed)

7. After Modify triggers again

8. Scenario 1: Flag is false ✓

9. Scenario 2: Quantity changed? NO (still 150) ✗

10. Rule skipped, no loop!

This is the foolproof pattern: Flag check + Change detection.

Part 6: Prevention Strategy #3 - Change-Detection Scenarios (5 minutes)

This is a simpler alternative when you don't have access to add custom flag fields.

How Change Detection Works

Add a scenario that checks if a specific field actually changed:

Scenario: {FieldID} is <>[FieldID]

Example:

Scenario: {37:15} is <>[37:15]

What this means:

• {37:15} = OLD value of field 15 (quantity)

• [37:15] = NEW value of field 15 (quantity)

• is <> = is not equal to

• So: "Old quantity is not equal to new quantity" = Quantity changed

How this prevents loops:

1. User changes quantity from 10 to 100

2. After Modify triggers

3. Scenario checks: Old (10) <> New (100)? YES ✓

4. Rule executes, sets discount = 15

5. After Modify triggers again (discount changed)

6. Scenario checks: Old quantity (100) <> New quantity (100)? NO ✗

7. Rule skipped, no loop!

Limitations of Change Detection

This method only works if:

• Your rule is based on a specific field changing

• That field doesn't change as a side effect of the rule itself

• You're OK with rule not running on other modifications

Example where it doesn't work:

Rule: Auto-calculate discount based on quantity
Scenario: {37:15} is <>[37:15]  // Quantity changed
Action: Assign [37:27] = {[37:15]

Actually, in this example it works fine. Let me show where it doesn't work:

Example where change detection fails:

Rule: Recalculate discounts when price changes
Scenario: {27:18} is <>[27:18]

Bottom line: Change detection is great for simple scenarios. For complex cross-table rules, use flag fields.

Part 7: Real-World Example #1 - Credit Limit Auto-Adjustment with Loop Protection (5 minutes)

Let's implement a real rule with full loop protection.

Business Requirement: When a customer's balance exceeds 80% of their credit limit, automatically increase the credit limit by 20%, but only once per day to prevent runaway increases.

Without protection, this would loop:

• Balance exceeds 80% of limit

• Rule increases limit by 20%

• Record is modified

• Rule triggers again

• Balance still exceeds 80% of NEW limit

• Rule increases limit again

• Infinite loop of limit increases

Protected implementation:

Custom Fields Added:
- [18:50000] QUA Credit Adjustment Flag (Boolean)
- [18:50001] Last Credit Adjustment Date (Date)

Rule Set: CUSTOMER-CREDIT-AUTO-ADJUST
Trigger: Customer (18) - After Modify
Trigger Type: After Modify

Scenarios:
1. [18:50000] is false  // Flag not set
2. [18:50001] is <>[TODAY]  // Not adjusted today
3. {18:61} is <>[18:61]  // Balance changed

Rule: Increase Credit Limit
  Condition: [18:61] is >{[18:59] * 0.8}  // Balance > 80% of limit
  
  Action 1 (Order 1): Assign [18:50000] = true  // Set flag
  
  Action 2 (Order 2): Assign [18:59] = {[18:59] * 1.2}  // Increase limit by 20%
  
  Action 3 (Order 3): Assign [18:50001] = [TODAY]  // Record adjustment date
  
  Action 4 (Order 4): Assign [18:50000] = false  // Clear flag
  
  Action 5 (Order 5): Notification
    Message: "Credit limit for [18:2] automatically increased from {[18:59]} to [18:59]

Protection mechanisms:

1. Flag field prevents immediate re-trigger

2. Date check prevents multiple adjustments same day

3. Balance change detection only triggers when balance actually changes

Test this rule:

1. Create customer with Credit Limit = 10,000

2. Post transactions to set Balance = 9,000 (90% of limit)

3. Check validation log

4. Verify limit increased to 12,000 (10,000 * 1.2)

5. Verify only ONE execution in log

6. Try posting more transactions same day

7. Verify rule doesn't trigger again (date check prevents it)

Part 8: Troubleshooting - What to Do When You Have a Loop (5 minutes)

Scenario: You just deployed a rule and now Business Central is frozen. What do you do?

Emergency Response Steps

Step 1: Disable the Rule Immediately

1. If you can still access Business Central, search for "Business Rule Sets"

2. Find the problematic rule set

3. Uncheck "Enable"

4. Save

5. Ask users to close and reopen their transactions

If Business Central is completely frozen:

1. Contact your system administrator

2. Have them stop the Business Central service

3. Access the database directly

4. Find the Business Rule Sets table

5. Set Enable = false for the problematic rule set

6. Restart service

Step 2: Review the Validation Log

Once the system is stable:

1. Search for "Validation Log"

2. Filter by Date = Today, Time = when incident occurred

3. Look for the rule that executed hundreds of times

4. Note the specific record it was looping on

5. Screenshot for documentation

Step 3: Identify the Problem

Check these things:

• Trigger Type: Is it "After Modify"?

• Actions: Is there an Assign action?

• Does Assign modify the trigger table?

• Are there scenarios preventing re-execution?

• Is there flag field protection?

• Are there multiple rules fighting over the same field?

Step 4: Apply Protection

Quick fixes (choose one):

• Change After Modify to Before Modify (if possible)

• Add change-detection scenario

• Implement flag field pattern

• Remove the Assign action (use different action type)

• Add condition that prevents re-execution

Step 5: Test in Sandbox

Before re-enabling:

1. Replicate rule in sandbox environment

2. Enable validation logging

3. Recreate the exact scenario that caused loop

4. Verify log shows only 1-2 executions

5. Test with multiple different scenarios

6. Get sign-off from stakeholders

Step 6: Deploy with Monitoring

1. Enable rule during low-activity period

2. Monitor validation log for first hour

3. Watch for any multiple executions

4. Have disable plan ready if problems recur

Part 9: Testing Checklist - Verify Your Rules Won't Loop (5 minutes)

Before deploying any rule with After Modify + Assign, complete this checklist.

Pre-Deployment Testing Checklist

☐ Check 1: Review Rule Configuration

• Is trigger type "After Modify" or "After Insert"?

• Does rule have Assign action?

• Does Assign modify the trigger table?

• If yes to all three → High loop risk, add protection

☐ Check 2: Verify Protection Mechanisms

• Flag field implemented? (best protection)

• OR change-detection scenario added?

• OR changed to Before trigger?

• At least one protection mechanism present?

☐ Check 3: Enable Validation Logging

• Business Rule Setup → Enable Validation Log = Yes

• Log Level = Detailed

• Confirmed logging is working?

☐ Check 4: Test in Sandbox

• Rule replicated in sandbox environment?

• Test data prepared?

• Multiple test scenarios planned?

☐ Check 5: Execute Test Scenarios

Test 1: Normal Operation

• Create/modify record that should trigger rule

• Check validation log

• Expected: 1-2 executions maximum

• Actual: _____ executions

Test 2: Rapid Repeated Modifications

• Modify same record 5 times quickly

• Check validation log

• Expected: 5-10 executions total (1-2 per modification)

• Actual: _____ executions

Test 3: Edge Cases

• Test with null/empty values

• Test with boundary conditions

• Test with maximum values

• All tests passed without loops?

☐ Check 6: Performance Testing

• Transaction completes in < 1 second?

• No timeout errors?

• CPU usage normal?

• Database performance acceptable?

☐ Check 7: Review Log Results

• Same rule executing more than 5 times for one transaction?

• If yes → Loop detected, do not deploy

• If no → Safe to proceed

☐ Check 8: Document Protection Method

• Rule description includes loop protection note?

• Example: "Loop protection: Flag field [50000]"

• Documentation updated?

☐ Check 9: User Communication

• Users informed about new rule?

• Expected behavior explained?

• Support contact provided?

☐ Check 10: Rollback Plan

• Know how to disable rule quickly?

• Administrator contact available?

• Backup plan documented?

All checkboxes checked? ✓ Safe to deploy to production.

Part 10: Best Practices Summary

Do's and Don'ts

✓ DO:

• Use Before triggers whenever possible for Assign actions

• Implement flag field protection for After triggers with Assign

• Add change-detection scenarios as additional protection

• Enable validation logging before testing

• Test in sandbox before production deployment

• Document your loop protection method

• Monitor validation log after deployment

• Plan for emergency disable procedure

✗ DON'T:

• Use After Modify + Assign without protection

• Deploy rules without testing in sandbox

• Ignore validation log warnings

• Create rules that modify each other's trigger tables

• Assume "it looks OK" without testing

• Deploy during peak business hours

• Skip the testing checklist

Quick Reference: When to Use Each Strategy

Before Trigger (Best):

• When: Assigning values in trigger table

• Pros: No loop risk at all, simplest solution

• Cons: Can't send emails, can't modify other tables

• Use this whenever possible

Flag Field Pattern (Most Reliable):

• When: Must use After trigger with Assign

• Pros: Bulletproof protection, works in all scenarios

• Cons: Requires custom field, slightly complex setup

• Use this for critical production rules

Change Detection (Simplest):

• When: Rule based on specific field changing

• Pros: No custom fields needed, simple to implement

• Cons: Won't prevent all loop types

• Use this for simple scenarios only

Real-World Wisdom

From 5+ years of rule building:

1. 90% of loops are caused by After Modify + Assign - Always question this pattern

2. Flag fields are worth the effort - Ask your developer to add flag fields to commonly-used tables (Sales Line, Sales Header, Purchase Line, etc.). You'll reuse them across many rules.

3. Validation log is your best friend - Check it after every test. Seeing 1-2 executions = good. Seeing 10+ = loop.

4. Test with real data - Loops sometimes only happen with specific data combinations. Test with production-like data.

5. Document everything - Six months from now, you won't remember why you added that flag field. Document your loop protection strategy in the rule description.

6. Start with Before triggers - Default to Before trigger unless you have a specific reason to use After.

7. One rule, one purpose - Don't create rules that do too many things. Simpler rules are less likely to loop.

Conclusion

Circular references are scary, but completely preventable. Now you have three solid strategies to protect against them:

1. Use Before triggers instead of After triggers (simplest)

2. Implement flag field protection (most reliable)

3. Add change-detection scenarios (quickest)

Key takeaways:

✓ After Modify + Assign = High loop risk (80% of circular references) ✓ Always enable validation logging when testing ✓ Test in sandbox before production deployment ✓ Flag field pattern provides bulletproof protection ✓ Before triggers eliminate loop risk entirely ✓ Use the testing checklist for every rule ✓ Document your protection method ✓ Have an emergency disable plan

Your action plan:

Today (15 minutes):

1. Audit your existing rules for After Modify + Assign patterns

2. Change to Before triggers where possible

3. Add protection to high-risk rules

This week (30 minutes):

1. Ask your developer to add flag fields to common tables

2. Implement flag field pattern on critical rules

3. Update rule documentation

Ongoing:

1. Use the testing checklist for all new rules

2. Monitor validation log after deployments

3. Share this guide with other rule builders

You're now equipped to build complex business rules with confidence, knowing your rules will never create another infinite loop.

Additional Resources

• QUALIA Rule Engine User Manual: Section 9 (Advanced Techniques)

• Blog: Understanding Trigger Events: Deep dive into Before vs After triggers

• Blog: Best Practices for Business Rule Design: Broader design principles

• Support: support@qualia-technik.com for complex scenarios

Questions or need help?

If you're dealing with a circular reference situation, don't panic:

1. Disable the rule immediately

2. Review this guide's troubleshooting section

3. Contact QUALIA support if needed

4. We're here to help!

Last Updated: December 1, 2025
Version: 1.0