Troubleshooting Guide

This section provides systematic diagnostic procedures, troubleshooting techniques, and proven solutions for common business rule problems. When business rules do not behave as expected, methodical troubleshooting quickly identifies root causes and enables effective resolution. The diagnostic procedures in this section are ordered from most common issues to progressively more complex scenarios.

22.1 Common Issues Overview and Quick Reference

Business rule problems typically fall into specific categories. Understanding these categories helps direct troubleshooting efforts to the most likely causes.

Issue Category 1: Rules Not Executing When Expected

Symptoms: Users report that validations are not occurring, or that expected messages/actions do not appear.

Most Common Causes:

• Enable checkboxes not selected (global, rule set, or individual rule level)

• Trigger configuration mismatch (wrong table or trigger type)

• Scenario configuration causing short-circuit before condition evaluation

• Rule Group membership preventing execution for specific users

• Trigger Field mismatch (rule triggers on different field than expected)

Initial Diagnostic: Check Validation Log to determine if rule executed at all

Issue Category 2: Rules Executing with Wrong Results

Symptoms: Rules execute, but conditions evaluate incorrectly, actions perform unexpected operations, or data modifications are incorrect.

Most Common Causes:

• Formula syntax errors (wrong operators, incorrect placeholder syntax)

• Incorrect table or field IDs in placeholders

• Linked Table relationships configured incorrectly

• Data type mismatches in comparisons

• Misunderstanding of Scenario logic (TRUE means skip, FALSE means continue)

Initial Diagnostic: Check Validation Log to see actual execution results and condition evaluations

Issue Category 3: Performance Problems

Symptoms: Transactions take significantly longer to complete than before rules were enabled. Users report system slowness during save operations.

Most Common Causes:

• Rules executing for every record instead of filtered subset (no Scenarios)

• Too many Linked Tables requiring multiple database lookups

• Any-field trigger [TableID:0] causing excessive executions

• Complex formula calculations in high-frequency scenarios

• Email actions or external system calls adding latency

Initial Diagnostic: Measure transaction time with rule disabled vs enabled

Issue Category 4: Error Messages Unclear or Unhelpful

Symptoms: Users see error messages but do not understand what is wrong or how to fix it.

Most Common Causes:

• Generic error text without specific context or values

• Missing explanations of what value is expected

• No guidance on how to resolve the problem

• Technical jargon inappropriate for business users

Initial Diagnostic: Review actual error message text in rule configuration

Issue Category 5: Linked Tables Not Working

Symptoms: Formulas referencing linked table fields return blank values, or rules fail with field not found errors.

Most Common Causes:

• Linked Table join condition configured incorrectly

• Related record does not exist (lookup finds no matching record)

• Field IDs incorrect in linked table placeholders

• Linked Tables defined in wrong order (chained relationships)

Initial Diagnostic: Verify related record exists and join fields contain expected values

Issue Category 6: Formulas Not Evaluating Correctly

Symptoms: Formulas that should evaluate to TRUE evaluate to FALSE, or vice versa. Calculated values are incorrect.

Most Common Causes:

• Operator syntax errors (= instead of is)

• Wrong placeholder syntax (curly braces instead of square brackets, or vice versa)

• Incorrect data type assumptions

• Misunderstanding of Business Central filter syntax

• Blank value handling not accounted for

Initial Diagnostic: Test formula with known data values and verify expected result

22.2 Rules Not Executing - Comprehensive Diagnostic Procedure

When rules do not execute at all, follow this systematic diagnostic procedure. Work through each check sequentially until the root cause is identified.

Diagnostic Step 1: Verify Global Enable Setting

The Business Rule Setup page contains a master Enable checkbox that controls all business rule processing across the entire Business Central environment.

How to Check:

1. Search for "Business Rule Setup" in Business Central

2. Open the Business Rule Setup page

3. Verify the Enable checkbox at the top of the page is selected (✓)

What It Means:

• If checkbox is NOT selected: No business rules execute anywhere in the system, regardless of other configuration

• If checkbox IS selected: Global enable is on; continue to next diagnostic step

Resolution: Select the Enable checkbox to activate business rule processing globally

💡 TIP: If you just enabled Business Rule Setup for the first time, users may need to log out and log back in for the change to take effect due to session caching.

Diagnostic Step 2: Verify Business Rule Set Enable Status

Each Business Rule Set has its own Enable checkbox that controls whether rules in that set execute.

How to Check:

1. Open the Business Rules list page

2. Locate your Business Rule Set in the list

3. Check the Enable column

4. Alternatively, open the Business Rule Card and check the Enable checkbox in the General tab

What It Means:

• If NOT enabled: This rule set is dormant; all rules within it are inactive

• If enabled: Rule set is active; continue to next diagnostic step

Resolution: Enable the Business Rule Set by selecting the Enable checkbox

Diagnostic Step 3: Verify Individual Business Rule Enable Status

Within an enabled Business Rule Set, each individual Business Rule (validation line) has its own Enable checkbox.

How to Check:

1. Open the Business Rule Set

2. Navigate to the Rules tab

3. Locate the specific Business Rule in the Conditions section

4. Check the Enable checkbox for that validation line

What It Means:

• If NOT enabled: This specific rule is inactive, but other rules in the set may still execute

• If enabled: This rule is active; continue to next diagnostic step

Resolution: Enable the specific Business Rule by selecting its Enable checkbox

Diagnostic Step 4: Verify Trigger Table Configuration

Business rules only execute for the table specified in the Trigger Table field. If the trigger table does not match the table where operations are occurring, rules will not execute.

How to Check:

1. Note which table you are creating/modifying records in (for example, Sales Line = Table 37)

2. Open your Business Rule Set

3. Check the Trigger Table field in the General tab

4. Verify it matches the table where operations occur

What It Means:

• If trigger table does NOT match: Rules will never execute for operations on the wrong table

• If trigger table DOES match: Trigger table is correct; continue to next diagnostic step

Resolution:

• If trigger table is wrong, you must create a new Business Rule Set with the correct trigger table

• You cannot change the trigger table after scenarios or conditions exist

Diagnostic Step 5: Verify Trigger Type Configuration

Business rules only execute for operation types (Insert, Modify, Delete) that are enabled in the trigger type configuration.

How to Check:

1. Note which operation you are performing (Insert = creating new record, Modify = changing existing record, Delete = removing record)

2. Open your Business Rule Set

3. Check the Trigger Insert, Trigger Modify, and Trigger Delete checkboxes

4. Verify the checkbox for your operation type is selected

What It Means:

• If operation's checkbox NOT selected: Rules will not execute for that operation type

• If operation's checkbox IS selected: Trigger type is correct; continue to next diagnostic step

Resolution: Select the checkbox for the operation type when rules should execute

Common Mistake: Many users configure rules with only Trigger Modify enabled, then wonder why rules do not execute when creating new records. Enable both Trigger Insert AND Trigger Modify if rules should apply to both operations.

Diagnostic Step 6: Verify Rule Group Membership

If a Business Rule Set is assigned to specific Rule Groups, it only executes for users who are members of those groups.

How to Check:

1. Open your Business Rule Set

2. Check if any Rule Groups are assigned to it

3. If Rule Groups ARE assigned, verify the current user is a member of at least one of those groups

4. To check user membership: Open Rule Groups page, open each assigned Rule Group, verify user is in the Users list

What It Means:

• If NO Rule Groups assigned: Rule executes for ALL users; Rule Groups are not the issue

• If Rule Groups assigned AND user IS a member: User membership is correct; continue to next diagnostic step

• If Rule Groups assigned AND user is NOT a member: Rules will not execute for this user

Resolution: Either add the user to an appropriate Rule Group, or remove Rule Group assignments from the Business Rule Set to make it apply to all users

Diagnostic Step 7: Check Scenario Configuration (Advanced)

IMPORTANT - COUNTER-INTUITIVE BEHAVIOR:

Scenarios are inclusion filters written in BC filter syntax. The CheckConditions function has inverted return logic:

• When ALL scenario filters MATCH the record → CheckConditions returns FALSE → Processing CONTINUES

• When ANY scenario filter does NOT match → CheckConditions returns TRUE → Processing STOPS

This means: Write scenario filters that MATCH the records you WANT to process.

How to Check:

1. Open your Business Rule

2. Check if any Scenarios are configured

3. For each Scenario, check if the filter MATCHES your test record

4. Remember: When filters MATCH, processing CONTINUES. When filters DON'T match, processing STOPS.

What It Means:

• If NO Scenarios configured: Scenarios are not the issue; continue to next diagnostic step

• If Scenarios configured and ANY filter does NOT match: Processing stops; conditions never evaluate

• If Scenarios configured and ALL filters MATCH: Processing continues; conditions should evaluate

Common Mistake: Users write Scenario: [36:120] is <>'0' thinking "exclude Open orders", but the filter is <>'0' MATCHES Released orders, so Released orders get processed (opposite of intent if you wanted Open orders).

Correct Mental Model: "Write filters for the records I want to process. When filters match, processing happens."

Example - Process Only Open Orders:

✅ Correct: Scenario: [36:120]

Filter is '0' MATCHES Open orders (Status=0) → Processing continues for Open orders

Example - Process Only Released Orders:

✅ Correct: Scenario: [36:120]

Filter is <>'0' MATCHES Released/Posted orders (Status<>0) → Processing continues for Released orders

Diagnostic Step 8: Check Trigger Field Specification

If a specific Trigger Field is configured, the rule only executes when that field changes (for Modify triggers) or is populated (for Insert triggers).

How to Check:

1. Open your Business Rule

2. Check the Trigger Field configuration

3. Verify which field(s) will trigger the rule

4. Confirm whether that field actually changed in your test transaction

What It Means:

• If Trigger Field is [TableID:0]: Rule triggers on ANY field change; Trigger Field is not the issue

• If Trigger Field specifies specific field(s): Rule only triggers when those fields change

• If your test transaction did not modify the specified field: Rule correctly did not execute

Resolution: Either modify the Trigger Field configuration to include the fields you are changing, or perform test transactions that modify the specified trigger fields

Diagnostic Step 9: Review Validation Log for Execution Evidence

The Validation Log provides definitive evidence of whether rules executed and what results occurred.

How to Check:

1. Search for "Validation Log" in Business Central

2. Filter the log by:

   • Date/Time: Recent (today or past hour)

   • User ID: Your user ID

   • Business Rule Set Code: Your rule set code

3. Check if any log entries exist for your test transactions

What It Means:

• If NO log entries exist: Rules did not execute at all; review previous diagnostic steps

• If log entries exist: Rules DID execute; issue is with condition evaluation or action execution, not rule triggering

Resolution: If no log entries exist after reviewing all previous diagnostic steps, contact QUALIA support with detailed configuration information

22.3 Formula Evaluation Problems - Detailed Diagnostics

When formulas do not evaluate as expected, systematic diagnosis of formula components identifies the issue.

Problem 22.3.1: Formula Always Returns FALSE (Condition Never Triggers)

Symptoms: You expect the condition to be TRUE and actions to execute, but nothing happens. Validation Log shows condition evaluated to FALSE.

Diagnostic Procedure:

Step 1: Verify Placeholder Syntax

Placeholders must use square brackets [], not curly braces {}, parentheses (), or angle brackets <>.

✅ Correct: [36:61] (square brackets)
❌ Wrong: {36:61}, (36:61), <36:61>

Step 2: Verify Table and Field IDs

Incorrect table or field IDs cause formulas to reference wrong data or return blank values.

How to Verify:

1. Check TableFieldMapping.csv or Business Central table/field lists

2. Verify table ID is correct for the table you intend to reference

3. Verify field ID is correct for the specific field

4. Common mistakes:

   • Using Table 36 (Sales Header) when you meant Table 37 (Sales Line)

   • Confusing field IDs between tables (field 15 means different things in different tables)

Step 3: Verify Comparison Operator Syntax

QUALIA Rule Engine uses is keyword, NOT equals sign =.

✅ Correct: [36:61] is >10000
❌ Wrong: [36:61] = >10000 or [36:61] > 10000 (missing is keyword)

Step 4: Verify Data Type Compatibility

Comparing incompatible data types may cause unexpected results.

Common Data Type Issues:

• Comparing numeric field to text value: [36:61] is '10000' (should be [36:61] is 10000 without quotes)

• Comparing text field to numeric value: [36:3] is 12345 (should be [36:3] is '12345' with quotes)

• Comparing date field to text: Ensure proper date format

Step 5: Test Formula Components Independently

Break complex formulas into simpler components and test each independently.

Example Complex Formula:

{([36:61] + [18:59]) / [18:20]

Test Components Separately:

1. First test: [36:61] is <>0 (verify Order Amount has value)

2. Second test: [18:59] is <>0 (verify Customer Balance has value)

3. Third test: [18:20] is <>0 (verify Customer Credit Limit has value)

4. Then test: {[36:61] + [18:59]} is >0 (verify calculation works)

5. Finally test full formula

Problem 22.3.2: Placeholder Returns Blank Value

Symptoms: Formula references a field but the value appears blank in Validation Log or conditions do not trigger as expected.

Diagnostic Procedure:

Cause 1: Field Not Yet Populated (Record Lifecycle Issue)

Context: During BeforeInsert triggers, only the primary key and a few default fields are populated. User-entered fields like Description, Type, Quantity are NOT yet available because users enter them AFTER the initial record creation.

How to Diagnose:

• Check which trigger type your rule uses (Insert, Modify, Delete)

• If BeforeInsert, verify the field you are referencing is actually populated at insert time

• Test by adding a Message action that displays the field value: "Value: [36:61]"

Resolution:

• For fields populated after record creation, use BeforeModify trigger instead of BeforeInsert

• Or validate during status transitions (when record changes from Draft to Released)

Cause 2: Linked Table Relationship Incorrect

Context: If you reference a field from a linked table but the join condition is wrong, QUALIA finds no matching record and returns blank.

How to Diagnose:

1. Open your Business Rule Set's Linked Tables configuration

2. Review the Reference Filter join condition

3. Verify the join fields contain expected values in both tables

4. Test: Create a simple condition that checks if the linked table field is blank: [18:2] is ''

Resolution:

• Correct the Linked Table join condition

• Verify related records actually exist (for example, customer record exists for customer number on order)

Cause 3: Field ID Incorrect

Context: Wrong field ID causes formula to reference a different field than intended.

How to Diagnose:

• Verify field ID against TableFieldMapping.csv

• Add Message action displaying field value to see what is actually retrieved

• Check whether you are using correct table ID as well as field ID

Resolution: Correct the field ID in your placeholder

Problem 22.3.3: Calculated Values Are Incorrect

Symptoms: Formulas with calculations {} return unexpected values.

Diagnostic Procedure:

Step 1: Verify Calculation Syntax

Calculations must be enclosed in curly braces {}.

✅ Correct: {[36:61] + [36:62]} (curly braces for calculation)
❌ Wrong: [36:61] + [36:62] (missing curly braces)

Step 2: Check Operator Precedence

Multiplication and division occur before addition and subtraction.

Example That May Surprise You:

{[37:15] * [37:22]

This calculates (Quantity × Price) + 10, NOT Quantity × (Price + 10)

To Force Specific Order: Use nested calculations

{[37:15] * {[37:22]

Step 3: Check for Division by Zero

Dividing by zero causes errors or unexpected results.

Example Problem:

{[36:61] / [18:20]

If Credit Limit is zero, division fails.

Safe Approach: Add Scenario to filter out zero values

Scenario: [18:20]

Step 4: Verify Placeholder Values in Calculation

Add Message action to display intermediate values.

Example Diagnostic Message:

"Debug: Amount=[36:61], Balance=[18:59], Limit=[18:20], Sum={[36:61]+[18:59]

This shows actual values being used in calculation, making errors obvious.

22.4 Performance Problems - Systematic Optimization

When business rules cause noticeable transaction delays, systematic performance analysis identifies bottlenecks and enables targeted optimization.

Problem 22.4.1: Slow Save Operations After Enabling Rules

Symptoms: Transactions that completed quickly before rules were enabled now take several seconds. Users complain about system slowness.

Diagnostic Procedure:

Step 1: Measure Baseline Performance

How to Measure:

1. Disable the suspect business rule (clear Enable checkbox)

2. Perform a typical transaction and time how long save operation takes

3. Record baseline time (for example, 200ms)

4. Re-enable the business rule

5. Perform the same transaction and time save operation

6. Record new time (for example, 2,500ms)

7. Calculate impact: 2,500ms - 200ms = 2,300ms added overhead (1,150% increase)

What It Means:

• <500ms total: Acceptable performance for most scenarios

• 500-1000ms: Noticeable but may be acceptable for critical validations

• 
  

1000ms: Significant performance problem requiring optimization

Step 2: Identify Performance Bottlenecks

Common Bottlenecks (in order of likelihood):

Bottleneck 1: No Scenarios (Processing Every Record)

Diagnosis: Check if rule has Scenarios configured. If no Scenarios exist, rule processes every single record.

Example Impact:

• Database has 10,000 sales orders

• Rule processes all 10,000 every time any order is touched

• Processing time: 10,000 × 250ms = 2,500 seconds (41 minutes) of cumulative processing

Resolution: Add Scenarios to filter to relevant subset

Scenario: [36:120]

Bottleneck 2: Too Many Linked Tables

Diagnosis: Count Linked Tables in rule configuration. Each linked table requires database lookup.

Performance Impact Per Linked Table:

• 0 linked tables: 50ms baseline

• 1 linked table: +25ms (75ms total)

• 3 linked tables: +75ms (125ms total)

• 5 linked tables: +150ms (200ms total)

Resolution: Remove unused Linked Tables. Only keep tables actually referenced in formulas.

Bottleneck 3: Any-Field Trigger Causing Excessive Executions

Diagnosis: Check Trigger Field configuration. [TableID:0] triggers on every field change.

Example Impact:

• User changes Customer Name on order: Rule executes

• User changes Ship-to Address: Rule executes

• User changes Order Date: Rule executes

• Each field change triggers credit validation unnecessarily

Resolution: Use specific Trigger Field

Change from: [36:0] (any field)
Change to: [36:61]

Bottleneck 4: Complex Formula Calculations

Diagnosis: Review formula complexity. Multiple nested calculations add processing time.

Example Complex Formula:

{({([36:61] * 1.08) + {[18:59] - [18:62]}} / [18:20]) * {1.0 + ([36:68]

This requires 8 arithmetic operations and 5 field lookups.

Resolution: Simplify formula or move complex logic to Custom Actions

Bottleneck 5: Email Actions or External Calls

Diagnosis: Check if rule has Email, URL, Power Automate, or Custom Actions that call external systems.

Performance Impact:

• Email action: +500-2,000ms (SMTP connection overhead)

• URL action: +200-500ms (browser launch)

• Power Automate: +300-1,000ms (HTTP call)

• Custom Action with API: varies widely

Resolution:

• Use threshold-based notifications (only for exceptional cases)

• Consider asynchronous patterns for external calls

• Batch notifications instead of individual calls

Step 3: Implement Optimizations and Retest

After implementing optimizations, repeat performance measurement to verify improvement.

Target Improvement: 80%+ reduction in added overhead

Example:

• Before optimization: 2,300ms overhead

• After optimization: 350ms overhead

• Improvement: 85% reduction (achieved target)

Problem 22.4.2: Rules Executing Too Frequently

Symptoms: Validation Log shows rules executing thousands of times per day. Performance degrades over time.

Diagnostic Procedure:

Step 1: Query Validation Log for Execution Frequency

How to Check:

1. Open Validation Log

2. Filter by date range (for example, past 7 days)

3. Count executions per Business Rule Set

4. Calculate average executions per day

Acceptable Frequency Guidelines:

• <100 executions/day: Excellent (targeted, specific rules)

• 100-500 executions/day: Good (moderate frequency)

• 500-2,000 executions/day: Acceptable (common operations)

• 
  

2,000 executions/day: Review needed (may be over-executing)

Step 2: Analyze Execution Patterns

Review log entries to understand why frequency is high.

Common Patterns:

Pattern: Executing for All Record Types

• Example: Rule executes for Quotes, Orders, Invoices, Credit Memos

• Resolution: Add Scenario filtering by Document Type

Pattern: Executing for Already-Posted Documents

• Example: Rule executes for documents with Status = Posted

• Resolution: Add Scenario filtering by Status field

Pattern: Executing During Batch Operations

• Example: Nightly batch job modifies 10,000 records, triggering rule 10,000 times

• Resolution: Consider whether rule should execute during batch operations; may need Rule Group strategy

Step 3: Optimize Trigger Configuration

Adjust Scenarios and Trigger Fields to reduce execution frequency.

Optimization Example:

Before:

Trigger Field: [36:0]

After:

Trigger Field: [36:61] (Amount only)
Scenario: [36:120] is <>'0' (Process Released/Posted orders only)
Executions: 250/day (95% reduction - processes only 5% of orders that are Released/Posted)

Note: If you want to process ONLY Open orders instead, use:
Scenario: [36:120]

22.5 Linked Table Problems - Diagnostic Procedures

Linked Tables enable cross-table validation but require correct configuration to function properly.

Problem 22.5.1: Linked Table Fields Return Blank Values

Symptoms: Formulas referencing linked table fields always show blank or zero, even though related records exist with populated values.

Diagnostic Procedure:

Step 1: Verify Linked Table Is Configured

How to Check:

1. Open Business Rule Set

2. Navigate to Linked Tables tab

3. Verify an entry exists for the table you are trying to reference

4. Verify the Reference Table number is correct

What It Means:

• If NO Linked Table entry exists: You cannot reference fields from that table; add Linked Table configuration

• If Linked Table entry EXISTS: Continue to next step

Step 2: Verify Reference Filter (Join Condition)

How to Check:

1. Open the Linked Table configuration

2. Review the Reference Filters subsection

3. Verify the join condition connects correct fields

Common Join Errors:

❌ Wrong Field IDs:

Should be: Customer.No. (Field 2) = Sales Header.Customer No. (Field 2)

❌ Wrong Filter Type:

This links to only one specific customer; should use Filter Type: Field

✅ Correct Configuration:

Step 3: Verify Related Record Exists

How to Check:

1. Note the value in the trigger record's join field (for example, Customer No. = "CUST001")

2. Search for that customer in the Customer table

3. Verify the customer record exists and has the expected field values

What It Means:

• If related record does NOT exist: Linked table lookup finds nothing; placeholders return blank

• If related record EXISTS but fields are blank: The fields themselves are blank in the database

• If related record EXISTS with values: Join condition is wrong

Resolution:

• Ensure related records exist before relying on linked table values

• Add error handling (Scenarios) to check for blank linked table values

• Use "If Not Found" setting on Linked Table to control behavior when record not found

Problem 22.5.2: Chained Linked Tables Not Working

Symptoms: You have Sales Line → Sales Header → Customer chained relationship, but Customer fields return blank.

Diagnostic Procedure:

Step 1: Verify Linked Tables Defined in Correct Order

QUALIA Rule Engine processes Linked Tables sequentially. Dependent tables must be defined AFTER their prerequisites.

✅ Correct Order:

❌ Wrong Order:

Resolution: Reorder Linked Tables so prerequisites come first

Step 2: Verify Intermediate Table References Use Correct Syntax

When chaining, the second link must reference fields from the first linked table using TableID:FieldID syntax.

✅ Correct Reference:

❌ Wrong Reference:

Step 3: Test Each Link Independently

Create separate test conditions for each link in the chain.

Test Condition 1 (Sales Line → Sales Header):

Condition: [36:3] is <>''  (Sales Header.No. is not blank)
Action: Message "Header No: [36:3]

Test Condition 2 (Sales Header → Customer):

Condition: [18:2] is <>''  (Customer.No. is not blank)
Action: Message "Customer No: [18:2], Name: [18:3]

If first test passes but second fails, the problem is in the second link's configuration.

22.6 Action Execution Problems

When conditions evaluate TRUE but actions do not execute as expected, diagnose action-specific issues.

Problem 22.6.1: Email Actions Not Sending

Symptoms: Condition triggers, Validation Log shows action executed, but email is never received.

Diagnostic Checklist:

☐ Permission Set: Verify user has "QUA Email Notification UnLicensed" permission set
☐ SMTP Configuration: Verify Business Central SMTP is configured correctly (test with standard BC email)
☐ Recipient Address: Verify email address is valid and not blank
☐ Spam Folder: Check recipient's spam/junk folder
☐ Email Relay: Verify mail server is processing and relaying emails
☐ Network Connectivity: Verify BC server can reach SMTP server on required port

Problem 22.6.2: Assign Actions Not Populating Fields

Symptoms: Condition triggers but field values are not assigned.

Diagnostic Checklist:

☐ Permission Set: Verify user has "QUA Universal Default Values UnLicensed" permission set
☐ Field Permissions: Verify user has write permission to target field
☐ Field ID Correct: Verify field ID in Code field is correct
☐ Value Syntax: Verify value is correctly formatted (text in quotes, numbers without)
☐ Read-Only Fields: Verify you are not attempting to assign read-only system fields
☐ Validate Flag: If Validate=Yes, check for OnValidate trigger issues (see Section 13.4)

Problem 22.6.3: Custom Actions Not Executing

Symptoms: Condition triggers but custom AL code does not execute.

Diagnostic Checklist:

☐ Permission Set: Verify user has "QUA Advanced Workflow UnLicensed" permission set
☐ Extension Deployed: Verify AL extension with event subscriber is deployed and published
☐ Action Code Match: Verify Action Code in rule matches code in AL event subscriber
☐ Event Subscriber Active: Verify event subscriber codeunit is not disabled
☐ Error Handling: Check if custom code is failing silently (add logging to AL code)

22.7 Using Validation Log for Diagnostics

The Validation Log is the most powerful diagnostic tool for troubleshooting business rules. Understanding how to query and interpret the log accelerates problem resolution.

Accessing and Filtering the Validation Log

How to Open:

1. Search for "Validation Log" in Business Central

2. The log displays all rule executions with newest entries first

Essential Filters:

Filter by Date/Time: Narrow to specific time period

Filter by User: See only specific user's rule executions

Filter by Business Rule Set: Focus on specific rule set

Filter by Result: Find failures or specific action types

Interpreting Log Entries

Each Validation Log entry contains critical diagnostic information:

Entry Date/Time: Exact timestamp when rule executed
User ID: Which user triggered the rule
Validation Set Code: Which Business Rule Set executed
Validation Code: Which specific rule (validation line) within the set
Table No.: Which table the operation occurred on
Record ID: Primary key value(s) of the record
Result: What happened (Success, Error, Message, etc.)
Error Text: Actual message displayed to user (for errors)
Execution Time: How long rule took to execute (if logged)

Diagnostic Patterns in the Log

Pattern 1: Rule Never Appears in Log

• Meaning: Rule is not executing at all

• Action: Work through Section 22.2 diagnostic procedure

Pattern 2: Rule Appears with Condition=FALSE

• Meaning: Rule executed but condition did not trigger

• Action: Review formula syntax and test with known data

Pattern 3: High Execution Frequency

• Meaning: Rule may be over-executing

• Action: Add Scenarios or adjust Trigger Field

Pattern 4: Intermittent Failures

• Meaning: Rule works sometimes but fails for specific data values

• Action: Examine failing record IDs to identify pattern in data causing failures

Pattern 5: Same Error Repeatedly for One User

• Meaning: That user consistently enters invalid data or lacks understanding

• Action: User training may be needed

22.8 Common Error Messages and Solutions

This section provides solutions for common error messages users encounter.

Error: "Field not found"

Cause: Formula references invalid field ID or field does not exist in specified table

Solutions:

1. Verify field ID against TableFieldMapping.csv

2. Check if field exists in the table version of Business Central you are using

3. Verify table ID is correct

Error: "Invalid filter expression"

Cause: Formula syntax error in condition

Solutions:

1. Verify you are using is keyword, not =

2. Check for unmatched parentheses or brackets

3. Verify placeholder syntax uses square brackets

4. Verify calculation syntax uses curly braces

Error: "Division by zero"

Cause: Formula attempts to divide by zero

Solutions:

1. Add Scenario filtering out zero values: [TableID:FieldID] is 0

2. Restructure formula to avoid division

Error: "Insufficient permissions"

Cause: User lacks required permission set for action type

Solutions:

1. For Email actions: Assign "QUA Email Notification UnLicensed"

2. For Assign actions: Assign "QUA Universal Default Values UnLicensed"

3. For Custom actions: Assign "QUA Advanced Workflow UnLicensed"

4. For Power Automate: Assign "QUA Power Automate Connector UnLicensed"

22.9 Escalation and Support

When troubleshooting procedures do not resolve issues, escalate to QUALIA support with comprehensive information.

Information to Gather Before Contacting Support:

☐ QUALIA Rule Engine version (1.1.0.4 or other)
☐ Business Central version and build number
☐ Business Rule Set Code and Name
☐ Complete description of expected behavior vs. actual behavior
☐ Steps to reproduce the problem reliably
☐ Validation Log excerpts showing problem occurrences
☐ Screenshots of rule configuration (if applicable)
☐ Screenshots of error messages (if applicable)
☐ Whether problem occurs for all users or specific users
☐ Whether problem occurs in sandbox and production
☐ Recent changes to rules or system configuration

Contact Information:

Email Support: info@qualiatechnik.de

Email Subject Format: "QUALIA Rule Engine [version] - [Brief Problem Description]"

Example: "QUALIA Rule Engine 1.1.0.4 - Credit validation not triggering for sales orders"

Response Time Expectations:

• Initial response: Within 1 business day

• Resolution time: Varies by complexity; critical production issues prioritized

22.5 Getting Help

Before Contacting Support:

1. Check Validation Log for error details

2. Test in sandbox to isolate the problem

3. Document steps to reproduce

4. Note exact error messages

5. Check whether problem occurs for all users or specific users

Contact Information:

Email Support: info@qualiatechnik.de

Email Subject Format: "QUALIA Rule Engine [version] - [Brief Problem Description]"

Example: "QUALIA Rule Engine 1.1.0.4 - Credit validation not triggering for sales orders"

Response Time Expectations:

• Initial response: Within 1 business day

• Resolution time: Varies by complexity; critical production issues prioritized