Chapter 4: Configuring Triggers and Rules

Triggers and scenarios are the intelligence behind notifications—they determine WHEN notifications appear and UNDER WHAT CONDITIONS. This chapter dives deep into trigger configuration, scenario creation, and the Rule Engine's evaluation logic. You'll learn how to monitor specific database events, filter trigger conditions with precision, write complex scenario formulas, and create sophisticated multi-condition rules.

Mastering triggers and scenarios is essential for creating notifications that fire at exactly the right moment with exactly the right context, without overwhelming users with irrelevant alerts.

4.1 Understanding Triggers

What Are Triggers?

Triggers monitor database tables for specific events (Insert, Modify, Delete) and initiate Rule Engine evaluation when those events occur. Without triggers, notifications would never fire—triggers are the mechanism that detects business events.

Trigger Components:

Every trigger configuration includes:

• Source Table: Which table to monitor (e.g., Sales Header table 36)

• Event Types: Which database operations to watch (Insert, Modify, Delete, Rename)

• Field Filters: Optionally, which specific fields matter (Trigger String)

How Triggers Work:

1. Business Central executes a database operation (user posts an order, modifies a customer, etc.)

2. The QUALIA Rule Engine has subscribers on table events

3. When a monitored table changes, the subscriber fires

4. The Rule Engine checks all triggers configured for that table

5. Matching triggers initiate notification evaluation

6. Scenarios check whether conditions are met

7. If conditions pass, notification displays

📋 NOTE: Triggers are evaluated AFTER the database operation completes and commits. You cannot use triggers to prevent operations or validate data before saving. Triggers are for notification and post-event processing only.

Trigger Types

The Advanced Notification App supports four trigger event types:

Trigger Insert (OnInsert Event):

• Fires when a new record is created in the table

• Use for: "New order created", "Customer added", "Item registered"

• Evaluates the newly inserted record

Trigger Modify (OnModify Event):

• Fires when an existing record is changed

• Use for: "Order status changed", "Customer credit limit updated", "Item price modified"

• Most common trigger type

• Can be filtered to specific fields using Trigger String

Trigger Delete (OnDelete Event):

• Fires when a record is removed from the table

• Use for: "Order cancelled", "Customer deleted", "Item discontinued"

• Evaluates the record's state just before deletion

• Less common—many BC processes prevent deletion of posted records

Trigger Rename (OnRename Event):

• Fires when a record's primary key value changes

• Use for: "Document renumbered", "Customer number changed"

• Rare in practice—most BC tables don't allow primary key changes after creation

💡 TIP: Start with Trigger Modify for most notifications. It's the most versatile—you can monitor status changes, field updates, and state transitions. Reserve Insert triggers for "new record" scenarios and Delete triggers for cancellation workflows.

Configuring Triggers

Triggers are configured in the Triggers subpage within the notification card's Triggers & Scenarios section.

Procedure: Add a Trigger

1. Open your notification card

2. Expand the Triggers & Scenarios section

3. In the Triggers subpage, click to add a new line

4. Configure fields:

   • Source Table No.: Enter the table number to monitor

   • Trigger Insert: Check if notification should fire on new records

   • Trigger Modify: Check if notification should fire on record changes

   • Trigger Delete: Check if notification should fire on record deletions

   • Trigger Rename: Check if notification should fire on primary key changes

   • Trigger String: (Optional) Enter comma-separated field numbers to filter modifications

5. Save the notification

✅ EXAMPLE - Sales Order Released Notification:

This configuration monitors the Sales Header table and triggers only when the Status field (field 5) is modified, ignoring changes to other fields.

Trigger String Filtering

The Trigger String is a powerful feature that prevents unnecessary evaluations by filtering which field changes matter.

Without Trigger String:

If you check Trigger Modify without specifying a Trigger String:

• Notification evaluates on ANY field change

• Changing customer name? Evaluates

• Changing shipping date? Evaluates

• Changing line item quantity? Evaluates

• This can result in excessive notifications

With Trigger String:

Specifying field numbers in Trigger String limits evaluation to those fields:

• Only evaluates when specified fields change

• Dramatically reduces unnecessary processing

• Prevents notification spam

Trigger String Syntax:

Enter field numbers as comma-separated values:

• Single field: 5

• Multiple fields: 5,79,110

• Spaces are ignored: 5, 79, 110 works the same

Common Trigger String Examples:

⚠️ WARNING: Trigger String filtering is case-sensitive to commas and requires exact field numbers. If your trigger never fires, verify:

1. Field numbers are correct for the source table

2. No spaces or typos in the trigger string

3. The field you're monitoring actually changes during your test scenario

When to Use Trigger Strings:

Use Trigger String when:

• Monitoring tables with many fields where only specific fields matter

• High-traffic tables where changes happen frequently

• You want to reduce performance overhead

Skip Trigger String when:

• Monitoring Insert/Delete events (Trigger String doesn't apply)

• You genuinely care about ANY field change

• The table has few fields and changes are infrequent

Multiple Triggers on One Notification

A single notification can have multiple trigger configurations, allowing it to fire from different tables or different events.

Example: Multi-Table Notification

Notification: "Document status changed"

Trigger 1:

• Source Table: 36 (Sales Header)

• Trigger Modify: Yes

• Trigger String: 5

Trigger 2:

• Source Table: 38 (Purchase Header)

• Trigger Modify: Yes

• Trigger String: 5

This notification fires when either sales documents OR purchase documents change status.

Example: Multi-Event Notification

Notification: "Customer record activity"

Trigger:

• Source Table: 18 (Customer)

• Trigger Insert: Yes

• Trigger Modify: Yes

• Trigger Delete: Yes

• Trigger String: (empty)

This notification fires on any customer record creation, modification, or deletion.

📋 NOTE: When using multiple triggers, scenarios evaluate against the specific record that triggered. If a Sales Header triggers the notification, scenarios reference Sales Header fields. If a Purchase Header triggers it, scenarios reference Purchase Header fields. Design your scenarios accordingly.

4.2 Creating Scenarios

What Are Scenarios?

While triggers determine WHEN to evaluate a notification, scenarios determine WHETHER to display it. Scenarios are conditional expressions that must evaluate to TRUE for the notification to appear.

Scenario Purpose:

Scenarios filter notifications based on data values:

• "Only notify if Status = Released"

• "Only notify if Amount > $10,000"

• "Only notify if Customer is Blocked"

• "Only notify during business hours"

Without scenarios, every trigger event would display a notification. Scenarios ensure notifications appear only when conditions warrant.

Scenario Evaluation:

When a trigger fires:

1. Rule Engine retrieves the record that triggered

2. Evaluates each scenario formula

3. Resolves placeholders to actual field values

4. Calculates the expression

5. If ALL scenarios evaluate to TRUE, notification displays

6. If ANY scenario evaluates to FALSE, notification is suppressed

Multiple scenarios use AND logic—all must pass.

Scenario Configuration

Scenarios are configured in the Scenarios subpage within the Triggers & Scenarios section.

Procedure: Add a Scenario

1. Open your notification card

2. In the Scenarios subpage, click to add a new line

3. Enter a Description explaining what this scenario checks

4. Enter a Validate String containing your condition formula

5. Save the notification

Scenario Fields:

Description (Text[100]):

• Human-readable explanation of the condition

• For documentation and troubleshooting

• "Status is Released", "Amount exceeds $10,000", "Customer is not blocked"

Validate String (Text[250]):

• The actual conditional expression

• Uses placeholder syntax

• Must evaluate to TRUE or FALSE

• "[36:5] = 1", "[36:110] > 10000", "[18:39] <> TRUE"

Scenario Formula Syntax

Scenario formulas use a specific syntax for comparing values:

Basic Comparison Operators:

• = Equal to

• <> Not equal to

• > Greater than

• < Less than

• >= Greater than or equal to

• <= Less than or equal to

Operand Types:

Placeholders (resolve to field values):

[36:5]        Table 36, Field 5 (resolves to actual value)
[18:59]

Literals:

• Numbers: 1000, 10000.50, -50

• Text: 'Released', 'APPROVED' (single quotes required)

• Dates: '2025-12-31', '2025-01-01' (ISO format, single quotes)

• Booleans: TRUE, FALSE (no quotes)

Basic Formula Structure:

[TableNo:FieldNo]

✅ EXAMPLE - Common Scenario Formulas:

[36:5] = 1                    // Sales Header Status equals 1 (Released)
[36:110] > 10000              // Amount Including VAT greater than 10,000
[18:39] = TRUE                // Customer Blocked equals TRUE
[36:79] <> ''                 // Sell-to Customer Name is not empty
[36:13]

Complex Scenario Formulas

For sophisticated conditions, you can use logical operators and grouping:

Logical AND:

[36:5] = 1 AND [36:110]

Both conditions must be true (Status is Released AND Amount exceeds 10,000)

Logical OR:

[36:5] = 1 OR [36:5]

Either condition can be true (Status is Released OR Status is Shipped)

Grouping with Parentheses:

([36:5] = 1 OR [36:5] = 2) AND [36:110]

Complex logic: (Status is Released or Shipped) and (Amount exceeds 10,000)

NOT Operator:

NOT [18:39]

Negates the condition (Customer is NOT blocked)

Alternatively: [18:39] <> TRUE achieves the same result

Range Checks:

[36:110] >= 1000 AND [36:110]

Amount between 1,000 and 50,000 (inclusive)

⚠️ WARNING: Complex formulas are powerful but can be hard to troubleshoot. Test thoroughly and document what each formula does. Consider splitting very complex scenarios into multiple simpler scenarios or multiple notifications.

Testing Scenario Formulas

Validating scenarios before deployment prevents issues:

Testing Approach:

1. Create test notification with code "TEST-SCENARIO"

2. Configure simple trigger on a test table

3. Add your scenario formula

4. Create/modify test records that should match

5. Verify notification appears for matching records

6. Create records that should NOT match

7. Verify notification does NOT appear for non-matching records

Common Scenario Errors:

Error: Scenario never passes (notification never displays)

Possible causes:

• Formula syntax error (mismatched parentheses, wrong operators)

• Wrong field numbers in placeholders

• Wrong data type (comparing number to text)

• Literal values wrong format (missing quotes on text)

Error: Scenario always passes (notification displays too often)

Possible causes:

• Formula logic inverted (using = instead of <>)

• Missing parentheses changing evaluation order

• Comparing wrong fields

Error: System error when evaluating

Possible causes:

• Invalid placeholder syntax

• Non-existent table or field numbers

• Data type mismatch (comparing date to number)

💡 TIP: Use the QUA Validation Log to troubleshoot scenarios. The log shows whether scenarios passed or failed for each evaluation, helping you understand what's happening.

Multiple Scenarios (AND Logic)

You can add multiple scenario rows to a single notification. All scenarios must evaluate to TRUE for the notification to display—they use AND logic.

Example: Multi-Scenario Notification

Notification: "Large order released"

Scenario 1:

• Description: Status is Released

• Validate String: [36:5] = 1

Scenario 2:

• Description: Amount exceeds $25,000

• Validate String: [36:110] > 25000

Evaluation:

• Trigger fires when Sales Header modified

• Scenario 1 checks: Is status Released? If NO → Stop, don't show notification

• Scenario 2 checks: Is amount > $25,000? If NO → Stop, don't show notification

• Both TRUE → Display notification

This ensures notifications only appear for large released orders, not small released orders or large unreleased orders.

When to Use Multiple Scenarios vs. Complex Formulas:

Multiple Scenarios:

• Easier to read and understand

• Easier to add/remove conditions

• Better for documentation

• Each scenario described separately

Complex Formula:

• More compact

• Can use OR logic between conditions

• Better for tightly-coupled logic

Use multiple scenarios when conditions are independent concepts. Use complex formulas when conditions are variations of the same concept.

4.3 Advanced Trigger and Scenario Patterns

Monitoring Status Changes

One of the most common notification patterns is detecting when a record's status field changes to a specific value:

Pattern: Status Change Detection

Configuration:

• Trigger: Modify event on source table

• Trigger String: Status field number

• Scenario: Check for specific status value

Example: Sales Order Released

Trigger:
  Source Table: 36
  Trigger Modify: Yes
  Trigger String: 5

Scenario:
  Description: Status is Released
  Validate String: [36:5]

This fires only when Status field changes AND the new value is 1 (Released).

Why This Works:

The Trigger String ensures evaluation only happens when field 5 changes. The scenario ensures the notification only appears when the new value is Released. Without the scenario, the notification would fire when status changes TO or FROM Released.

Threshold Monitoring

Notifications can alert users when values cross thresholds:

Pattern: Threshold Alert

Example: Customer Credit Limit Exceeded

Trigger:
  Source Table: 18 (Customer)
  Trigger Modify: Yes
  Trigger String: 59 (Balance field)

Scenario:
  Description: Balance exceeds credit limit
  Validate String: [18:59] > [18:27]

This compares Balance (LCY) field 59 against Credit Limit (LCY) field 27.

Example: Low Inventory Alert

Trigger:
  Source Table: 27 (Item)
  Trigger Modify: Yes
  Trigger String: 99 (Inventory FlowField)

Scenario:
  Description: Inventory below reorder point
  Validate String: [27:99] < [27:22]

This compares Inventory against Reorder Point.

📋 NOTE: FlowField triggers can be performance-intensive if FlowFields calculate frequently. Test thoroughly in realistic data volumes. Consider using scheduled batch jobs instead of real-time notifications for non-urgent inventory monitoring.

Time-Based Conditions

Scenarios can check dates and times to create time-sensitive notifications:

Pattern: Date Range Filtering

Example: Orders Due This Week

Scenario 1:
  Description: Shipment date is upcoming
  Validate String: [36:20] >= TODAY()

Scenario 2:
  Description: Shipment date is within 7 days
  Validate String: [36:20]

Example: Overdue Notifications

Scenario:
  Description: Due date has passed
  Validate String: [36:15]

Supported Date Functions:

• TODAY() - Current date

• TODAY() + n - n days from now

• TODAY() - n - n days ago

💡 TIP: Date-based scenarios evaluate at trigger time. An order due tomorrow will only trigger notifications when the record is modified, not automatically when tomorrow arrives. For automatic daily checks, consider scheduled notifications via job queue entries.

User-Based Filtering

Scenarios can check who performed an action:

Pattern: User Detection

Example: Notify on External User Changes

Scenario:
  Description: Modified by external user
  Validate String: [36:30]

This checks the Last Modified By user ID and notifies only if it's not the ADMIN user.

Example: Notify Specific User's Activity

Scenario:
  Description: Created by sales team
  Validate String: [36:30]

This uses pattern matching to detect users with IDs starting with "SALES".

⚠️ WARNING: User ID comparisons are case-sensitive and must match exactly. Verify user ID values in your environment before using in scenarios. BC uses the User Name field (User ID), not the Full Name.

Multi-Table Scenario Patterns

When using related table placeholders, you can create scenarios that check data across relationships:

Pattern: Related Record Filtering

Example: Notify for VIP Customer Orders

Trigger:
  Source Table: 36 (Sales Header)
  Trigger Modify: Yes
  Trigger String: 5

Scenario:
  Description: Customer is VIP
  Validate String: [18:5054]

This assumes a custom Boolean field 5054 on Customer table marking VIP status. When a sales order status changes, the scenario checks the related customer's VIP flag.

How Related Placeholders Work:

The Rule Engine:

1. Detects Sales Header trigger

2. Retrieves the triggered Sales Header record

3. Follows the relationship to Customer table

4. Evaluates the Customer field in the scenario

This requires a valid table relation from Sales Header to Customer.

This completes Chapter 4. Users now understand triggers, scenarios, formula syntax, complex conditions, and common notification patterns.