Using Old Value Placeholders for Change Detection and Validation

A Complete Guide to Tracking What Changed, When, and By How Much

Introduction

You're building a rule that should only trigger when a price increases—not when it decreases or stays the same. Or you need to detect when someone changes a discount from an approved value to something different. Or you want to send a notification showing exactly what changed: "Price increased from $100 to $150".

How do you access the old value—what the field was before the change?

This is where old value placeholders become essential. They let you compare what a field was (before the modification) to what it is now (after the modification). This unlocks powerful change detection capabilities that are impossible without old values.

Real-world scenario: Your sales manager wants a rule that blocks price decreases greater than 10%. You need to:

• Know the OLD price (before user changed it)

• Know the NEW price (after user changed it)

• Calculate the difference

• Block if decrease exceeds 10%

Without old values, you can't do this. With old values, it's straightforward.

This guide teaches you everything about old value placeholders: what they are, when they're available, how to use them, common patterns, and real-world examples.

What you'll learn:

✓ What old value placeholders are - Understanding {TableID:FieldID} syntax
✓ When old values are available - Only on Modify triggers (crucial limitation)
✓ Change detection patterns - Detecting if specific fields changed
✓ Value comparison patterns - Comparing old vs. new values
✓ Percentage change calculations - Detecting significant changes
✓ Audit trail messages - Showing "changed from X to Y" in messages
✓ Common mistakes - Pitfalls and how to avoid them
✓ Real-world examples - Price change validation, discount protection, status tracking

Time required: 30 minutes
Difficulty: Intermediate
Prerequisites:

• Microsoft Dynamics 365 Business Central with QUALIA Rule Engine installed

• Understanding of trigger events (Before/After Insert/Modify)

• Experience with placeholders [TableID:FieldID] in Business Central

• Basic rule creation skills

Let's master old value placeholders and unlock powerful change detection capabilities.

Part 1: Understanding Old Value Placeholders (5 minutes)

What Are Old Value Placeholders?

In QUALIA Rule Engine for Microsoft Dynamics 365 Business Central, there are TWO types of placeholders:

Current Value Placeholders (what you already know):

• Syntax: [TableID:FieldID]

• Example: [27:18] = Current value of Item Unit Price in Business Central

• Available: Always (Insert, Modify, Delete triggers)

Old Value Placeholders (what we're learning):

• Syntax: {TableID:FieldID} - Notice the curly braces instead of square brackets

• Example: {27:18} = OLD value of Item Unit Price in Business Central (before the change)

• Available: ONLY on Modify triggers (Before Modify, After Modify)

A Simple Example That Shows the Difference

Let's say a user changes an item's unit price from $100 to $150.

During the Modify trigger:

• {27:18} = 100 (old value - what it WAS)

• [27:18] = 150 (new value - what it IS now)

In formulas and conditions, you can compare them:

• {27:18} is <>[27:18] = "Old price is not equal to new price" = Price changed

• {([27:18] - {27:18}) / {27:18}} = (150 - 100) / 100 = 0.50 = 50% increase

• [27:18] is >{27:18} = 150 > 100 = TRUE = Price increased

This unlocks powerful capabilities:

• Detect which fields changed (ignore irrelevant modifications)

• Detect how much values changed (percentage increase/decrease)

• Detect direction of change (increase vs. decrease)

• Show before and after in messages ("Changed from $100 to $150")

• Validate change magnitude ("Don't allow price decreases > 10%")

Critical Limitation: Only Available on Modify Triggers

Old values ONLY exist during Modify triggers:

✓ Before Modify: Old values available
✓ After Modify: Old values available
✗ Before Insert: No old values (record didn't exist before)
✗ After Insert: No old values (record was just created)
✗ Before Delete: No old values (current values are the "old" values)
✗ After Delete: No old values (record is gone)

Why this matters: If you try to use {TableID:FieldID} on an Insert trigger, you'll get an error or null value. Always verify your trigger type before using old value placeholders.

Syntax Reminder: Curly Braces vs. Square Brackets

Easy way to remember:

• [Square brackets] = Current value = "NOW"

• {Curly braces} = Old value = "WAS"

In messages:

"Price changed from {27:18} to [27:18]

In formulas:

{([27:18]

Part 2: Change Detection Patterns (5 minutes)

The most common use of old values is detecting if a specific field changed.

Pattern 1: Detect If ANY Change Occurred

Formula: {FieldID} is <>[FieldID]

Example: Detect if unit price changed:

Scenario: {27:18} is <>[27:18]

What this means:

• "Old unit price is not equal to new unit price"

• = "Unit price changed"

Why use this:

• Rules only run when price actually changes

• Ignores modifications to other fields

• Improves performance (rules skip irrelevant modifications)

Real-world use case:

Rule Set: ITEM-PRICE-CHANGE-NOTIFICATION
Trigger: Item (27) - After Modify

Scenario: {27:18} is <>[27:18]  // Price changed
Rule: Notify Price Change
  Action: Email
    To: purchasing@company.com
    Subject: "Price changed for item [27:3]"
    Message: "Price changed from {27:18} to [27:18]

Placeholders Used:

• {27:18} - Item (Table 27): Unit Price (Field 18) - OLD value (before change)

• [27:18] - Item (Table 27): Unit Price (Field 18) - NEW value (current)

• [27:3] - Item (Table 27): Description (Field 3) - Item description

Pattern 2: Detect Multiple Field Changes

Formula: Use separate Conditions for OR logic

Example: Trigger if price OR cost changed:

Condition 1: {27:18} is <>[27:18]
// Triggers if unit price changed

Condition 2: {27:22} is <>[27:22]

What this means:

• "Unit price changed OR unit cost changed"

• Rule runs if either field changes

• Each Condition triggers independently (OR logic)

Alternative: Check if BOTH changed:

Scenario 1: {27:18} is <>[27:18]
Scenario 2: {27:22} is <>[27:22]

What this means:

• "BOTH price and cost must have changed"

• More restrictive

• Multiple Scenarios create AND logic (all must pass)

Placeholders Used:

• {27:18} - Item (Table 27): Unit Price (Field 18) - OLD unit price

• [27:18] - Item (Table 27): Unit Price (Field 18) - NEW unit price

• {27:22} - Item (Table 27): Unit Cost (Field 22) - OLD unit cost

• [27:22] - Item (Table 27): Unit Cost (Field 22) - NEW unit cost

Pattern 3: Detect Specific Direction of Change

Detect increases only:

Scenario: [27:18]

What this means: New price > old price = Price increased

Detect decreases only:

Scenario: [27:18]

What this means: New price < old price = Price decreased

Real-world example:

Rule Set: ITEM-PRICE-INCREASE-APPROVAL
Trigger: Item (27) - Before Modify

Scenario 1: {27:18} is <>[27:18]  // Price changed
Scenario 2: [27:18] is >{27:18}   // Price increased (not decreased)

Rule: Require Approval
  Condition: {([27:18] - {27:18}) / {27:18}} is >0.10  // Increase > 10%
  Action: Error
    Message: "Price increase of {(([27:18] - {27:18}) / {27:18}) * 100}% requires approval. Old price: {27:18}, New price: [27:18]

Placeholders Used:

• {27:18} - Item (Table 27): Unit Price (Field 18) - OLD unit price (before change)

• [27:18] - Item (Table 27): Unit Price (Field 18) - NEW unit price (current)

• {([27:18] - {27:18}) / {27:18}} - Calculated expression: Percentage change ((new - old) / old)

• {(([27:18] - {27:18}) / {27:18}) * 100} - Calculated expression: Percentage change as whole number

Pattern 4: Detect Magnitude of Change

Detect if change exceeds threshold:

Condition: {([27:18]

What this means: Absolute difference > 10 = "Price changed by more than $10"

Detect percentage change:

Condition: {([27:18]

What this means: (New - Old) / Old > 0.15 = "Price increased by more than 15%"

Absolute value (increase OR decrease):

Condition: {ABS([27:18]

What this means: Absolute value of difference > 10 = "Price changed by more than $10 in either direction"

Placeholders and Calculations Used:

• {27:18} - Item (Table 27): Unit Price (Field 18) - OLD value

• [27:18] - Item (Table 27): Unit Price (Field 18) - NEW value

• {([27:18] - {27:18})} - Calculated expression: Absolute change amount

• {([27:18] - {27:18}) / {27:18}} - Calculated expression: Percentage change (decimal)

• {ABS([27:18] - {27:18})} - Calculated expression: Absolute value of change (ignores direction)

Part 3: Common Use Cases and Patterns (10 minutes)

Use Case 1: Price Change Validation

Business requirement: Block item price decreases greater than 10% without manager approval.

Implementation:

Rule Set: ITEM-PRICE-DECREASE-PROTECTION
Trigger: Item (27) - Before Modify

Scenario 1: {27:18} is <>[27:18]  // Price changed
Scenario 2: [27:18] is <{27:18}   // Price decreased

Rule: Block Large Decreases
  Condition: {({27:18} - [27:18]) / {27:18}} is >0.10  // Decrease > 10%
  Action: Error
    Message: "Price decrease from {27:18} to [27:18] ({({27:18} - [27:18]

What this does:

• Only triggers when price changes (Scenario 1)

• Only checks decreases, not increases (Scenario 2)

• Calculates percentage decrease: (Old - New) / Old

• Blocks if decrease > 10%

• Shows user the exact old/new values and percentage

Test example:

• Old price: $100

• User changes to: $85

• Calculation: (100 - 85) / 100 = 0.15 = 15% decrease

• Result: Blocked with error showing 15% decrease

Use Case 2: Discount Change Audit Trail

Business requirement: Log all changes to sales line discounts for audit purposes, showing old and new values.

Implementation:

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

Scenario: {37:27} is <>[37:27]  // Discount % changed

Rule: Log Discount Change
  Action: Insert (into custom Audit Log table)
    Fields:
      - Table ID: 37
      - Record ID: [37:3]  // Document No.
      - Field Name: "Line Discount %"
      - Old Value: {37:27}
      - New Value: [37:27]
      - Changed By: [USERID]
      - Changed Date: [TODAY]
      - Changed Time: [CT]

What this creates:

Business value: Complete audit trail of who changed what, when, and by how much.

Use Case 3: Status Change Notifications

Business requirement: Send email notification when sales order status changes from "Open" to "Released", showing who released it and when.

Implementation:

Rule Set: SALES-ORDER-STATUS-NOTIFICATION
Trigger: Sales Header (36) - After Modify

Scenario 1: {36:120} is <>[36:120]  // Status changed
Scenario 2: {36:120} is 'Open'      // Was Open
Scenario 3: [36:120] is 'Released'  // Now Released

Rule: Notify Order Released
  Action: Email
    To: sales-manager@company.com
    Subject: "Sales Order [36:3] Released"
    Message: "Sales order [36:3] for customer [18:2] has been released by [USERID] on [TODAY] at [CT]. 
    
Previous status: {36:120}
Current status: [36:120]
Order amount: [36:109]

What this does:

• Only triggers when status field changes

• Only when changing FROM "Open" TO "Released" (not other status changes)

• Email shows old status, new status, who made the change, and when

Use Case 4: Credit Limit Monitoring

Business requirement: Send alert when customer credit limit is decreased, showing old and new limits.

Implementation:

Rule Set: CUSTOMER-CREDIT-LIMIT-DECREASE-ALERT
Trigger: Customer (18) - After Modify

Scenario 1: {18:59} is <>[18:59]  // Credit limit changed
Scenario 2: [18:59] is <{18:59}   // Limit decreased (not increased)

Rule: Alert on Decrease
  Action: Email
    To: finance@company.com; credit-manager@company.com
    Subject: "Credit Limit Decreased - [18:2]"
    Message: "ALERT: Credit limit for customer [18:2] has been decreased by [USERID].

Old limit: {18:59}
New limit: [18:59]
Decrease amount: {[18:59] - [18:59]}
Decrease percentage: {({18:59} - [18:59]) / {18:59} * 100}%
Current balance: [18:61]

Why this is valuable:

• Finance team immediately knows when limits are reduced

• Can verify change is authorized

• Helps prevent accidental decreases

• Shows exact amounts and percentages

Use Case 5: Quantity Change Threshold Alert

Business requirement: Alert warehouse when sales line quantity changes by more than 50 units.

Implementation:

Rule Set: SALES-LINE-QUANTITY-CHANGE-ALERT
Trigger: Sales Line (37) - After Modify

Scenario: {37:15} is <>[37:15]  // Quantity changed

Rule: Alert Large Changes
  Condition: {ABS([37:15] - {37:15})} is >50  // Change > 50 units in either direction
  Action: Notification
    Message: "Quantity on order [36:3] line [37:4] changed from {37:15} to [37:15] (change of {[37:15]

What this does:

• Detects quantity changes in either direction (increase or decrease)

• Uses ABS() function to get absolute value

• Only alerts if change exceeds 50 units

• Shows old quantity, new quantity, and difference

Part 4: Percentage Change Calculations (5 minutes)

Calculating Percentage Increase

Formula: {([FieldID] - {FieldID}) / {FieldID}}

Example: Calculate price increase percentage:

{([27:18]

How it works:

• Old price: $100

• New price: $150

• Calculation: (150 - 100) / 100 = 50 / 100 = 0.50

• Result: 0.50 = 50% increase

Convert to percentage: Multiply by 100:

{([27:18]

Result: 50 (represents 50%)

Calculating Percentage Decrease

Formula: {({FieldID} - [FieldID]) / {FieldID}}

Example: Calculate price decrease percentage:

{({27:18} - [27:18]

How it works:

• Old price: $100

• New price: $85

• Calculation: (100 - 85) / 100 = 15 / 100 = 0.15

• Result: 0.15 = 15% decrease

Note: For decreases, put OLD value first in subtraction to get positive percentage.

Comparing to Thresholds

Detect if increase exceeds 10%:

Condition: {([27:18]

Detect if decrease exceeds 10%:

Condition: {({27:18} - [27:18]

Detect if change in EITHER direction exceeds 10%:

Condition: {ABS([27:18]

Avoiding Division by Zero

Problem: If old value is zero, you can't calculate percentage change.

Old price: $0 New price: $100 Calculation: (100 - 0) / 0 = ERROR (division by zero)

Solution: Add condition to check old value is not zero:

Condition 1: {27:18} is <>0  // Old price was not zero
Condition 2: {([27:18]

Alternative: Use absolute change instead of percentage when old value is zero:

Scenario 1: {27:18} is 0
Scenario 2: {[27:18]

What this means: "If old price was zero, check if absolute increase > $10"

Part 5: Real-World Example - Price Change Protection (5 minutes)

Let's build a complete rule with old values that implements sophisticated price change validation.

Business Requirement:

• Allow price increases without restriction

• Block price decreases > 10% unless reason provided

• Send notification for all price changes > 5% in either direction

• Show detailed change information in all messages

Implementation:

Custom Fields Added:
- [27:50000] Price Change Reason (Text[100])

Rule Set: ITEM-PRICE-CHANGE-MANAGEMENT
Trigger: Item (27) - Before Modify

Scenario 1: {27:18} is <>[27:18]  // Price changed
Scenario 2: {27:18} is <>0         // Old price was not zero (avoid division by zero)

Rule 1: Block Large Decreases Without Reason
  Conditions:
    1. [27:18] is <{27:18}  // Price decreased
    2. {({27:18} - [27:18]) / {27:18}} is >0.10  // Decrease > 10%
    3. [27:50000] is ''  // No reason provided
  
  Action: Error
    Message: "PRICE DECREASE BLOCKED

Item: [27:3] - [27:8]

Old Price: {27:18}
New Price: [27:18]
Decrease: {[27:18] - [27:18]} ({({27:18} - [27:18]) / {27:18} * 100}%)

Price decreases greater than 10% require explanation in the Price Change Reason field. Please provide a reason for this price decrease before saving."

Rule 2: Notify on Significant Changes
  Condition: {ABS([27:18] - {27:18}) / {27:18}} is >0.05  // Change > 5% in either direction
  
  Action: Email
    To: pricing-team@company.com
    Subject: "Price Change Alert - [27:3]"
    Message: "Item price changed by more than 5%:

Item: [27:3] - [27:8]
Old Price: {27:18}
New Price: [27:18]
Change: {[27:18] - {27:18}} ({([27:18] - {27:18}) / {27:18} * 100}%)
Reason: [27:50000]
Changed By: [USERID]
Date/Time: [TODAY] [CT]

What this does:

Scenario 1: Only runs when price actually changes (not when other fields change) Scenario 2: Prevents division by zero errors

Rule 1 (Error):

• Checks if price DECREASED (new < old)

• Calculates percentage decrease

• If > 10%, checks if reason field is empty

• If empty, blocks with detailed error message

• User must fill in reason before saving

Rule 2 (Notification):

• Calculates absolute percentage change (increase or decrease)

• If > 5%, sends email to pricing team

• Email shows all details: old/new prices, change amount, percentage, reason, who, when

Test Scenarios:

Test 1: Small decrease (should allow):

• Old: $100, New: $95 = 5% decrease

• Result: Allowed (Rule 1 condition not met)

Test 2: Large decrease without reason (should block):

• Old: $100, New: $85 = 15% decrease

• Reason field: Empty

• Result: Error message displayed

Test 3: Large decrease with reason (should allow):

• Old: $100, New: $85 = 15% decrease

• Reason field: "Clearance sale"

• Result: Allowed, email sent (Rule 2 triggers)

Test 4: Large increase (should allow and notify):

• Old: $100, New: $120 = 20% increase

• Result: Allowed, email sent (Rule 2 triggers)

Part 6: Common Mistakes and How to Avoid Them (5 minutes)

Mistake 1: Using Old Values on Insert Triggers

Wrong:

Rule Set: CUSTOMER-VALIDATION
Trigger: Customer (18) - Before Insert

Scenario: {18:59} is <>[18:59]

Why it's wrong: Insert means creating a new record. There's no "old value" because the record didn't exist before.

Fix: Only use old values on Modify triggers:

Rule Set: CUSTOMER-VALIDATION
Trigger: Customer (18) - Before Modify  // Changed to Modify

Scenario: {18:59} is <>[18:59]

Mistake 2: Forgetting Curly Braces

Wrong:

Scenario: [27:18] is <>[27:18]

What this means: "Current price is not equal to current price" = Always false

Fix: Use curly braces for old value:

Scenario: {27:18} is <>[27:18]

What this means: "Old price is not equal to current price" = Price changed

Mistake 3: Division by Zero

Wrong:

Condition: {([27:18]

Fix: Check old value is not zero first:

Condition 1: {27:18} is <>0  // Old price not zero
Condition 2: {([27:18]

Mistake 4: Wrong Order in Subtraction for Decreases

Wrong (for detecting decreases):

Condition: {([27:18]

What this calculates:

• Old: $100, New: $85

• Calculation: (85 - 100) = -15 (negative number)

• Condition: -15 > 10? FALSE (missed the decrease!)

Fix: Put old value first for decreases:

Condition: {({27:18} - [27:18]

What this calculates:

• Old: $100, New: $85

• Calculation: (100 - 85) = 15 (positive number)

• Condition: 15 > 10? TRUE (correctly detected!)

Or use absolute value:

Condition: {ABS([27:18]

Mistake 5: Using Old Values in Actions (Limited Support)

Potentially problematic:

Action: Assign
  Field: [27:50000]

Better approach: Store old value in a separate field using Before Modify trigger:

Rule Set: ITEM-PRICE-HISTORY
Trigger: Item (27) - Before Modify

Scenario: {27:18} is <>[27:18]  // Price changing

Rule: Store Previous Price
  Action: Assign
    Field: [27:50001]  // "Last Price"
    Value: [27:18]

Mistake 6: Comparing Different Field Types

Wrong:

Scenario: {27:8} is <>[27:18]

Fix: Only compare same field to itself:

Scenario: {27:18} is <>[27:18]

Part 7: Testing Old Value Placeholders (3 minutes)

Test Procedure

Step 1: Enable Validation Logging

• Business Rule Setup → Enable Validation Log = Yes

• Log Level = Detailed

Step 2: Create Test Scenario

1. Open the record you'll modify

2. Note the current value (this will become the "old value")

3. Change the field to a new value

4. Save

Step 3: Verify Rule Behavior

• Check if rule triggered (look for notification/error/email)

• Check validation log

Step 4: Review Validation Log

1. Search for "Validation Log"

2. Filter to your test time

3. Check "Scenario Result" - should show "Pass" if field changed

4. Check "Condition Result" - should show evaluation results

5. Check "Action Result" - should show action executed

Test Cases for Price Change Example

Test 1: Field Changed (Should Trigger)

• Old value: $100

• New value: $150

• Scenario {27:18} is <>[27:18] should pass

• Expected: Rule runs

Test 2: Field Unchanged (Should NOT Trigger)

• Old value: $100

• New value: $100

• Scenario {27:18} is <>[27:18] should fail

• Expected: Rule skipped

Test 3: Different Field Changed (Should NOT Trigger)

• Change description, keep price at $100

• Scenario {27:18} is <>[27:18] should fail (price didn't change)

• Expected: Rule skipped

Test 4: Percentage Calculation

• Old value: $100

• New value: $115

• Condition: {([27:18] - {27:18}) / {27:18}} is >0.10

• Calculation: (115 - 100) / 100 = 0.15 = 15%

• Expected: Condition TRUE (15% > 10%)

Part 8: Best Practices Summary

Do's

✓ DO use old values for change detection:

Scenario: {FieldID} is <>[FieldID]

✓ DO use Before Modify when possible:

• Allows blocking changes before they're saved

• More efficient than After Modify for validation

✓ DO check for division by zero:

Condition 1: {FieldID} is <>0  // Old value not zero
Condition 2: {([FieldID]

✓ DO show old and new values in messages:

Message: "Changed from {FieldID} to [FieldID]

✓ DO use scenarios for performance:

Scenario: {FieldID} is <>[FieldID]

Don'ts

✗ DON'T use old values on Insert triggers:

• Old values only exist on Modify triggers

• Will cause errors or null values

✗ DON'T forget curly braces:

• {FieldID} = old value

• [FieldID] = current value

• They're different!

✗ DON'T compare unrelated fields:

Wrong: {27:8} is <>[27:18]  // Description vs. Price
Right: {27:18} is <>[27:18]

✗ DON'T ignore direction in subtraction:

• For decreases: (Old - New)

• For increases: (New - Old)

• Or use ABS() for both directions

✗ DON'T assume old value exists:

• Check trigger type is Modify

• Add error handling for edge cases

Conclusion

Old value placeholders unlock powerful change detection and validation capabilities:

What you now know: ✓ Old values use {TableID:FieldID} syntax (curly braces) ✓ Only available on Modify triggers (Before/After Modify) ✓ Essential for detecting what changed and by how much ✓ Enable sophisticated percentage change validation ✓ Create detailed audit trails showing before/after ✓ Improve performance by filtering irrelevant modifications

Key patterns to remember:

Change detection: {FieldID} is <>[FieldID] Percentage change: {([FieldID] - {FieldID}) / {FieldID}} Direction checking: [FieldID] is >{FieldID} (increase) or [FieldID] is <{FieldID} (decrease) Safe division: Check {FieldID} is <>0 first Descriptive messages: "Changed from {FieldID} to [FieldID]"

Your next steps:

Today:

1. Review existing rules that should use change detection

2. Add scenarios with {FieldID} is <>[FieldID] to improve performance

3. Test with validation logging enabled

This week:

1. Implement one rule using old values (try the price change example)

2. Add audit trail logging for critical field changes

3. Create notifications showing before/after values

Ongoing:

• Use old values whenever validating changes

• Always include change detection in Modify trigger scenarios

• Show old and new values in all change-related messages

You now have the knowledge to build sophisticated change detection and validation rules using old value placeholders!

Additional Resources

• QUALIA Rule Engine User Manual: Section 9.5 (Placeholders)

• Blog: Understanding Trigger Events: When to use Before vs. After Modify

• Blog: Creating Your First Business Rule: Foundation for rule building

• Blog: Circular Reference Protection: Important when using Modify triggers

Last Updated: December 1, 2025
Version: 1.0