Testing and Validation Framework

Testing business rules before deploying them to production is not just a best practice—it is an absolute requirement for maintaining data integrity and preventing disruptions to business operations. This section explains why testing is critical, how to set up effective test environments, what testing scenarios you should cover, how to use the Validation Log to verify rule behavior, and how to troubleshoot common issues that arise during testing.

6.1 Why Testing Business Rules is Critical

Business rules in QUALIA Rule Engine execute automatically in response to database operations, which means they intercept and can potentially block or modify every transaction that occurs in the trigger table. A poorly designed or incorrectly configured rule can have severe consequences for your organization's operations, ranging from minor user inconvenience to complete inability to perform essential business functions.

Understanding the Impact of Business Rules

When you create a business rule with an Error Message action, that rule has the power to completely prevent users from saving records in Business Central. If the rule's validation logic is too strict, contains errors, or fails to account for legitimate business scenarios, users will encounter errors when trying to perform normal business operations. This can result in:

Work Stoppage: If a critical business process is blocked by an incorrectly configured rule, users cannot complete their work until the rule is fixed or disabled. For example, if a sales order validation rule is too restrictive, your sales team may be unable to enter orders, directly impacting revenue and customer satisfaction.

Data Quality Issues: Paradoxically, rules that are too strict can actually cause data quality problems. When users encounter validation errors they believe are incorrect, they may find workarounds that involve entering incorrect or misleading data just to bypass the validation. This defeats the purpose of the rule and introduces new data quality issues.

User Frustration and Resistance: Validation rules that display confusing error messages, block legitimate transactions, or require excessive manual workarounds will frustrate users and create resistance to the business rules system as a whole. This can undermine the effectiveness of all your business rules, even the correctly configured ones.

System Performance Degradation: Business rules execute on every qualifying database operation. Rules that are inefficiently designed, contain complex calculations, or access many linked tables can cause noticeable performance degradation. In extreme cases, poorly optimized rules can make Business Central feel slow and unresponsive.

Compliance and Audit Risks: If business rules are supposed to enforce compliance requirements but are incorrectly configured, your organization may unknowingly violate policies or regulations. Discovering during an audit that your validation rules were not working correctly can have serious legal and financial consequences.

The Cost of Fixing Production Issues

Discovering and fixing a business rule problem after it has been deployed to production is significantly more expensive and disruptive than catching the same problem during testing:

Immediate User Impact: The moment a problematic rule is activated in production, real users performing real business transactions begin encountering problems. This immediately disrupts business operations.

Emergency Response Required: Production issues typically require immediate attention, pulling administrators and consultants away from planned work to troubleshoot and resolve the issue urgently.

Difficult Diagnosis: When problems occur in production, they are often reported by frustrated users who may not provide complete or accurate information about what they were doing when the error occurred. This makes diagnosis more difficult than in a controlled test environment.

Risk of Incomplete Fixes: The pressure to restore normal operations quickly may lead to incomplete fixes or workarounds that address the immediate symptom but do not fully resolve the underlying problem.

Testing Prevents These Problems

Thorough testing in a sandbox environment allows you to discover and resolve these issues before they affect real users and real business operations. The time invested in testing is a small fraction of the time that would be required to respond to production incidents.

6.2 Setting Up an Effective Test Environment

Microsoft strongly recommends that all business rule development and testing be performed in a sandbox environment, not in your production Business Central environment. A sandbox is a copy of your production environment that allows you to experiment with configuration changes without risk to live business data or operations.

Creating a Sandbox Environment in Business Central Online

If you use Business Central Online (SaaS), you can create sandbox environments directly from the Business Central administration center:

1. Sign in to the Business Central administration center with an administrator account

2. Navigate to the Environments section

3. Select New to create a new environment

4. Choose Sandbox as the environment type

5. Select whether to create a sandbox as a copy of your production environment (recommended for testing business rules) or as a blank environment

6. Wait for the sandbox creation process to complete, which typically takes 15-30 minutes

Once your sandbox is ready, it contains a complete copy of your production environment's data and configuration, but operates independently. Changes made in the sandbox do not affect production, and vice versa.

Accessing Your Sandbox Environment

After creating a sandbox, you can access it through a separate URL that is distinct from your production environment URL:

1. In the Business Central administration center, locate your sandbox environment in the environments list

2. Note the URL provided for the sandbox (typically follows the pattern: https://businesscentral.dynamics.com/[tenant]/[sandbox-name])

3. Open this URL in your web browser to access the sandbox environment

4. Sign in with the same credentials you use for production (user accounts are copied to the sandbox)

Keeping Sandbox Data Current

Sandbox environments contain a static copy of production data from the time the sandbox was created. As time passes, this data becomes outdated. For realistic testing of business rules, you should periodically refresh your sandbox to bring in current production data:

1. In the Business Central administration center, select your sandbox environment

2. Choose the Copy from Production or Restore from Production option

3. Confirm that you want to overwrite the current sandbox data

4. Wait for the copy operation to complete

⚠️ WARNING: Refreshing a sandbox from production erases all configuration changes and test data in the sandbox. If you have business rules that you were testing in the sandbox, export or document them before refreshing, then recreate them in the refreshed sandbox.

Alternative: Using a Test Company in Production

If you cannot create a sandbox environment, an alternative (though less ideal) approach is to create a dedicated test company within your production environment:

1. In Business Central, search for "Companies" and open the Companies page

2. Create a new company specifically for testing purposes (for example, "Test Company - Do Not Use for Real Transactions")

3. Configure this company with sample data that resembles production scenarios

4. Perform all business rule testing in this test company, never in companies that contain real business data

⚠️ CRITICAL: Even when using a test company, you are still working in the production environment. Business Rule Sets that are not restricted by Rule Groups will execute in ALL companies, including live companies. Always use Rule Groups to restrict test rules to the test company only, or ensure test rules are disabled before saving them.

Preparing Test Data

Effective testing requires realistic test data that represents the scenarios your business rules need to handle:

Representative Data Volume: If your production environment has thousands of customer records, your test environment should have a similar volume. Some performance issues only become apparent with realistic data volumes.

Edge Cases: Include test data that represents unusual but legitimate scenarios, such as customers with very high credit limits, items with unusual pricing structures, or orders with many lines.

Invalid Data Scenarios: Create test data that should trigger your validation rules, such as negative quantities, invalid customer numbers, or missing required information.

Normal Scenarios: Include plenty of routine, valid test data to verify that your rules do not interfere with normal operations.

6.3 Comprehensive Test Scenario Coverage

Thorough testing requires systematically working through multiple test scenarios that cover both normal operations and edge cases. This section provides a structured approach to test scenario development.

Core Test Scenario Categories

For every business rule you create, you should test scenarios in the following categories:

1. Happy Path Testing - Valid Data

The happy path represents normal, valid business operations where users enter correct data and no validation errors should occur:

Test Objective: Verify that the rule allows valid transactions to proceed normally without displaying error messages or causing unexpected behavior.

Test Procedure:

1. Enter data that fully complies with your business rule requirements

2. Verify that no error messages or warnings appear

3. Verify that the transaction saves successfully

4. Verify that any non-blocking actions (Assign, Email, Notification) execute correctly

Example: For a quantity validation rule, enter positive quantities like 1, 10, 100, and verify they are accepted.

2. Validation Failure Testing - Invalid Data

Test scenarios where users enter data that should trigger validation errors:

Test Objective: Verify that the rule correctly detects invalid data and responds appropriately with clear error messages that prevent the transaction.

Test Procedure:

1. Enter data that violates your business rule requirements

2. Verify that an appropriate error message appears

3. Verify the error message is clear and helpful

4. Verify that the transaction is not saved

5. Verify that users can correct the error and retry successfully

Example: For a quantity validation rule, enter zero and negative quantities, verify error messages appear, and verify the lines are not saved.

3. Boundary Value Testing - Edge Cases

Test values at the boundaries of acceptable ranges:

Test Objective: Verify that the rule correctly handles values at the exact boundary between valid and invalid.

Test Procedure:

1. Test the maximum acceptable value

2. Test one value above the maximum (should fail)

3. Test the minimum acceptable value

4. Test one value below the minimum (should fail)

Example: If your rule requires quantities between 1 and 999:

• Test Quantity = 1 (should pass)

• Test Quantity = 0 (should fail)

• Test Quantity = 999 (should pass)

• Test Quantity = 1000 (should fail)

4. Trigger Type Testing - Insert vs. Modify vs. Delete

Test each trigger type that your rule is configured to handle:

Test Objective: Verify that the rule executes correctly for all configured trigger types and does not execute for trigger types that are not configured.

Test Procedure:

1. If Trigger Insert is enabled, test creating new records (both valid and invalid)

2. If Trigger Modify is enabled, test modifying existing records (both valid and invalid changes)

3. If Trigger Delete is enabled, test deleting records (if applicable to your rule)

4. Verify the rule does not execute for trigger types that are disabled

Example: For a sales line validation rule with Insert and Modify triggers:

• Create a new line with invalid data (should fail)

• Create a valid line, then modify it to have invalid data (should fail)

• Delete a line (should not trigger validation if Delete trigger is not enabled)

5. Linked Table Testing - Related Data Validation

If your rule uses Linked Tables to access data from related tables, test scenarios where the related data varies:

Test Objective: Verify that the rule correctly retrieves data from linked tables and handles scenarios where related records do not exist or contain unexpected values.

Test Procedure:

1. Test with related records that contain typical values

2. Test with related records that contain edge case values

3. Test scenarios where related records might not exist (if applicable)

4. Verify that incorrect join conditions do not cause the rule to retrieve wrong data

Example: For a credit limit validation rule that links Sales Header to Customer:

• Test with customers who have normal credit limits

• Test with customers who have zero or unlimited credit limits

• Test with customers who are blocked

• Verify the rule retrieves the correct customer record (not a different customer's data)

6. Performance Testing - High Volume Scenarios

Test rule performance under realistic data volumes:

Test Objective: Verify that the rule executes quickly enough that users do not experience noticeable delays when saving records.

Test Procedure:

1. Create test scenarios with realistic data volumes (for example, sales orders with 50-100 lines)

2. Time how long it takes to save records with the rule active

3. Compare to save times with the rule disabled

4. Verify that any delay is acceptable for normal business operations

Target Performance: Individual rule executions should complete in milliseconds. If users notice delays (more than 1-2 seconds), investigate rule optimization.

7. Rule Group Testing - User-Specific Rules

If your rule is assigned to specific Rule Groups, test with users in different groups:

Test Objective: Verify that the rule executes for users who are in the assigned groups and does not execute for users who are not in those groups.

Test Procedure:

1. Sign in as a user who is in the Rule Group (rule should execute)

2. Perform test operations and verify the rule triggers correctly

3. Sign in as a user who is not in the Rule Group (rule should not execute)

4. Perform the same operations and verify the rule does not trigger

Special Testing Considerations

Some types of business rules require additional testing considerations:

Confirmation Actions: Test both the Yes and No paths to verify that the correct actions execute based on user choice.

Email Actions: Verify that emails are sent to the correct recipients with the correct content. Check spam folders if test emails do not arrive.

Assign Actions: Verify that field values are populated correctly and that assigned values do not get overwritten by subsequent processes.

Power Automate Actions: Verify that flows trigger correctly and that data passes correctly between Business Central and Power Automate.

6.4 Using the Validation Log for Testing and Troubleshooting

The Validation Log is an essential tool for verifying that your business rules are working correctly and for diagnosing issues when rules do not behave as expected. QUALIA Rule Engine automatically creates a log entry every time a business rule executes, providing a complete audit trail of rule activity.

Accessing the Validation Log

To open the Validation Log in Business Central:

1. Use the search function at the top of Business Central (magnifying glass icon or Alt+Q)

2. Enter "Validation Log" in the search box

3. Select Validation Log from the search results

Business Central opens the Validation Log page, which displays a list of all rule execution events in reverse chronological order (most recent entries first).

Understanding Validation Log Columns

The Validation Log displays multiple columns that provide detailed information about each rule execution:

Entry No.: This column contains a unique sequential number for each log entry. Entry numbers increment automatically, and you can use them to identify specific log entries when discussing issues with colleagues or support.

User ID: This column shows which Business Central user account triggered the rule execution. This is valuable for understanding usage patterns, investigating issues reported by specific users, and analyzing which users or departments are most affected by validation rules.

Trigger Table No.: This column displays the table number where the rule executed. For example, "37" indicates Sales Line table. You can filter by this column to see all rule executions for a specific table.

Trigger Table Name: This column displays the human-readable name of the trigger table, such as "Sales Line" or "Sales Header". This makes it easier to understand what area of Business Central the rule applies to without needing to memorize table numbers.

Rule Set Code: This column shows the code of the Business Rule Set that executed. If you have multiple rule sets for the same table, this column helps you identify which rule set was involved in a particular execution.

Condition Description: This column displays the description you entered for the validation condition. Clear, descriptive condition names make the Validation Log much more useful for understanding what the rule was checking.

Result: This column indicates whether the validation condition evaluated to TRUE or FALSE. A TRUE result means the condition detected a problem or pattern that matched its criteria. A FALSE result means the condition did not match.

Action Executed: This column shows what action executed as a result of the condition evaluation. For conditions that evaluated to TRUE, this typically shows actions like "Error Message", "Send Email", etc. For conditions that evaluated to FALSE, this shows "No Action" or is blank.

Date and Time: These columns show exactly when the rule executed, which is essential for correlating log entries with user activities or investigating issues that occurred at specific times.

Filtering and Searching the Validation Log

The Validation Log can contain thousands or millions of entries over time. To find relevant entries quickly, use Business Central's filtering capabilities:

Filtering by Date Range:

1. Locate the Date column header

2. Select the dropdown arrow or right-click the column header

3. Choose "Filter" and enter a date range (for example, "Today" or "Last Week" or a specific date)

Filtering by User:

1. Locate the User ID column

2. Use the filter function to show only entries for a specific user

3. This is particularly useful when investigating issues reported by a specific user

Filtering by Table:

1. Use the Trigger Table No. or Trigger Table Name column filter

2. Enter the table number or name to see only rule executions for that table

3. This helps you focus on rules related to a specific functional area

Filtering by Rule Set:

1. Use the Rule Set Code column filter

2. Enter the rule set code to see all executions of a specific rule set

3. This is useful when testing a newly created rule to verify it is executing correctly

Filtering by Result:

1. Use the Result column filter

2. Filter to show only TRUE results to see cases where validation failed

3. Filter to show only FALSE results to verify that rules are not triggering incorrectly

Interpreting Validation Log Entries for Testing

During testing, the Validation Log helps you verify that your rule is working correctly:

Verifying Rule Execution: After performing a test transaction, immediately check the Validation Log. You should see a new entry showing that your rule executed. If no entry appears, the rule did not execute—possible causes include:

• The rule is disabled

• The trigger table or trigger type does not match the operation

• The user is not in the rule's Rule Group (if applicable)

• The global Business Rule Setup is disabled

Verifying Condition Evaluation: Check the Result column. If your test used invalid data that should trigger the rule, the Result should be TRUE. If your test used valid data that should pass validation, the Result should be FALSE.

Verifying Action Execution: Check the Action Executed column. If the Result was TRUE, you should see the action you configured (Error Message, Email, etc.). If the Result was FALSE, the Action Executed should show "No Action" because actions only execute when conditions are TRUE.

Troubleshooting with the Validation Log

When a rule does not work as expected, the Validation Log provides clues about what went wrong:

Problem: Rule Never Executes

Symptoms: No entries appear in the Validation Log when you perform operations that should trigger the rule.

Diagnosis Steps:

1. Verify the rule is enabled (both the Business Rule Set Enable checkbox and the individual rule Enable checkbox)

2. Verify the global Business Rule Setup Enable checkbox is selected

3. Verify the trigger table matches the table where you are performing operations

4. Verify the trigger type (Insert/Modify/Delete) matches the operation you are performing

5. Verify you are in the correct Rule Group if the rule is group-specific

Problem: Rule Executes But Condition Always FALSE

Symptoms: Log entries appear, but the Result column always shows FALSE even when you enter data that should trigger validation.

Diagnosis Steps:

1. Verify your validation formula syntax is correct (check for typos in placeholders or comparison operators)

2. Verify placeholder field IDs are correct (use F6 field lookup to verify)

3. Check if the comparison operator is correct (for example, "is >" instead of "is <")

4. Verify the comparison value is correct (check for extra spaces or incorrect data types)

Problem: Rule Blocks Valid Transactions

Symptoms: Log entries show Result = TRUE and Error Message executed, but you believe the data is valid.

Diagnosis Steps:

1. Review the validation formula—it may be checking for the opposite condition

2. Review the comparison value—it may be set incorrectly

3. Check if the rule is reading the correct field (verify placeholder field IDs)

4. Verify that linked tables are retrieving the correct related records

Validation Log Retention and Maintenance

The Validation Log grows continuously as rules execute. Organizations with many active rules executing frequently can accumulate millions of log entries over time:

Storage Considerations: Log entries consume database storage space. Very large Validation Log tables can impact database performance and backup/restore times.

Retention Policy: Most organizations implement a retention policy where log entries older than a certain period (for example, 90 days, 6 months, or 1 year) are periodically deleted. The appropriate retention period depends on your compliance requirements and how you use the log for analysis.

Archiving Historical Data: Before deleting old log entries, consider archiving them to external storage if you may need to reference them for compliance audits or long-term analysis.

6.5 Common Test Failures and How to Resolve Them

Even experienced QUALIA Rule Engine users encounter test failures. This section describes common problems discovered during testing and provides systematic resolution approaches.

Failure Pattern 1: Rule Executes on Wrong Trigger Type

Symptom: The rule executes when you modify a record, but you only wanted it to execute on insert operations (or vice versa).

Root Cause: The Trigger Type checkboxes in the Business Rule Set General tab do not match your intention. You may have selected multiple trigger types when you only wanted one, or forgotten to select a trigger type you need.

Resolution:

1. Open the Business Rule Set in edit mode

2. Navigate to the General tab

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

4. Select only the trigger types that are appropriate for your business requirement

5. Save the changes and retest

Failure Pattern 2: Rule Triggers on Every Field Change, Not Just Specific Fields

Symptom: When testing Modify operations, the rule executes even when you change fields that are not relevant to the validation. For example, a quantity validation rule executes when you change the Description field.

Root Cause: The Trigger Field configuration is set to [TableID:0] (any field) instead of specifying the specific field or fields that should trigger the rule.

Resolution:

1. Open the individual Business Rule (validation line) for editing

2. Locate the Trigger Field configuration

3. Change from [TableID:0] to [TableID:SpecificFieldID]

4. For the quantity example, use [37:15] to trigger only on Quantity field changes

5. Save and retest

Failure Pattern 3: Error Message is Confusing or Unhelpful

Symptom: The rule executes correctly and displays an error message, but users do not understand what the problem is or how to fix it.

Root Cause: The error message text does not clearly explain what is wrong, why it is wrong, and what users should do.

Resolution:

1. Rewrite the error message following these guidelines:

   • Start with a clear statement of what is wrong ("Quantity cannot be zero or negative")

   • Optionally explain why the requirement exists ("Zero quantities cause inventory processing errors")

   • Tell users what to do ("Please enter a quantity of 1 or greater")

2. Update the error action message text

3. Retest and verify the new message is clearer

Failure Pattern 4: Rule Allows Invalid Data in Edge Cases

Symptom: The rule correctly validates most scenarios, but allows certain invalid values to pass through. For example, a discount percentage rule allows 100.01% discount even though it should cap at 100%.

Root Cause: The comparison operator or comparison value does not account for all invalid cases. Often this involves confusion between "greater than" (>) and "greater than or equal to" (>=), or between "less than" (<) and "less than or equal to" (<=).

Resolution:

1. Review the validation formula carefully

2. Identify what condition makes data invalid

3. Verify the comparison operator correctly identifies that condition

4. Adjust the formula if needed

5. Create specific boundary value tests for the edge cases that failed

Example:

• Wrong: [Field] is >100 (allows 100, but 100 might be invalid)

• Right: [Field] is >=100 (catches 100 and anything greater)

Failure Pattern 5: Rule Blocks Users from Correcting Errors

Symptom: When users enter invalid data and receive an error, they correct the data, but the error appears again even though the data is now valid.

Root Cause: The rule is evaluating other fields or conditions that the user has not addressed. For example, a rule might validate both Quantity and Unit Price, and even if the user fixes Quantity, the error still appears because Unit Price is also invalid.

Resolution:

1. Review the complete validation formula to identify all fields and conditions being checked

2. Ensure the error message mentions all fields that must be corrected

3. Alternatively, split complex validation into multiple rules with specific error messages for each issue

4. Retest the correction process to verify users can successfully fix the error

Failure Pattern 6: Performance is Unacceptably Slow

Symptom: Saving records takes noticeably longer with the rule active than with the rule disabled. Users complain about system slowness.

Root Cause: The rule contains inefficient logic, accesses too many linked tables, performs complex calculations, or executes for too many records due to missing scenario filters.

Resolution:

1. Add Scenarios to filter out records that do not need validation (this prevents evaluation for 90%+ of records)

2. Minimize the number of Linked Tables used

3. Simplify complex calculations in formulas

4. Consider breaking one complex rule into multiple simpler rules

5. Use the Trigger Field specification to ensure the rule only executes when relevant fields change

6. Measure performance improvement after each optimization

Failure Pattern 7: Rule Interferes with Automated Processes

Symptom: The rule works correctly when users manually enter data, but causes errors when data is imported through web services, APIs, or batch processing jobs.

Root Cause: Automated processes may provide data in different formats, in different field order, or may temporarily create records with incomplete information that is filled in by subsequent operations.

Resolution:

1. Add Scenarios that check whether the current operation is being performed by an automated process (for example, check specific flag fields)

2. Consider whether the validation is appropriate for automated processes or should only apply to manual data entry

3. Modify the validation logic to accommodate legitimate data entry patterns used by automated processes

4. Coordinate with the developers or consultants who maintain the automated processes to understand their data entry patterns

Failure Pattern 8: Linked Table Retrieves Wrong Record

Symptom: The rule executes, but error messages reference incorrect data (for example, showing the wrong customer name or credit limit).

Root Cause: The Linked Table join condition is incorrect, causing QUALIA Rule Engine to retrieve the wrong related record or to retrieve no record at all.

Resolution:

1. Review the Linked Table configuration carefully

2. Verify the join fields are correct (which field in the trigger table should match which field in the linked table)

3. Verify the join condition retrieves the intended record

4. Test with multiple scenarios to ensure the correct related record is retrieved in all cases

5. Use the Validation Log to see what values the rule evaluated (this can help identify when wrong data is being retrieved)

6.6 Best Practices for Testing Business Rules

Experience has shown that certain testing approaches consistently produce better results and catch more issues before deployment. This section summarizes proven best practices.

Test Early and Test Often

Do not wait until you have completed a complex rule with multiple conditions and actions before testing. Instead:

Incremental Testing Approach:

1. Create the basic rule structure and test that the rule executes (even with incomplete logic)

2. Add the validation formula and test that it evaluates correctly for both valid and invalid data

3. Add the first action and test that it executes correctly

4. Add additional actions one at a time, testing after each addition

5. Add Scenarios or Linked Tables incrementally, testing after each addition

This incremental approach makes it easy to identify exactly what change caused a problem if testing suddenly fails.

Maintain a Test Case Library

As you test business rules, document the specific test cases you use:

Test Case Documentation Should Include:

• Description of what the test case validates

• Specific data values to enter

• Expected result (error message should appear, transaction should save successfully, etc.)

• Actual result when you performed the test

• Date tested and who performed the test

Maintaining this documentation allows you to:

• Repeat the same tests after making changes to verify nothing broke

• Hand off testing responsibilities to colleagues who can follow your test cases

• Demonstrate to auditors or stakeholders that rules were thoroughly tested

Test with Real Users Before Production Deployment

After completing technical testing, conduct user acceptance testing (UAT) where actual end users perform their normal work tasks in the test environment:

UAT Benefits:

• Users may attempt operations or data entry patterns that technical testers did not consider

• Users can evaluate whether error messages are clear and helpful from their perspective

• Users can identify whether rules interfere with legitimate business processes

• Getting user buy-in before production deployment reduces resistance and support issues

Plan Rollback Procedures

Before enabling a rule in production, ensure you know how to quickly disable it if problems arise:

Rollback Plan:

1. Document how to access the Business Rule Set and clear the Enable checkbox

2. Ensure multiple people have permissions to disable rules (do not depend on a single administrator)

3. Consider having a colleague ready to assist during initial production deployment in case issues arise

4. Monitor the Validation Log actively for the first few hours after enabling a rule in production

Document Rules for Future Maintenance

Clear documentation helps future maintainers (including yourself months later) understand the purpose and logic of business rules:

Documentation Should Include:

• Business requirement the rule enforces (why does this rule exist?)

• Description of the validation logic (what does it check?)

• Explanation of why specific trigger types and trigger fields were selected

• Notes about edge cases or special scenarios the rule handles

• Contact information for the business owner who can clarify requirements if questions arise