3.1 Opening Business Rules Setup

The Business Rules Setup page contains global configuration settings that affect how QUALIA Rule Engine behaves across your entire Business Central environment. This page should be configured by system administrators before business users begin creating rules.

To access Business Rules Setup:

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

2. Enter "Business Rule Setup" in the search box

3. Select Business Rule Setup from the results

The setup page opens, displaying global configuration options.

3.2 Understanding Validation Sets

In QUALIA Rule Engine terminology, a Validation Set (also called a Business Rule Set) is a container that groups related business rules together. Each Validation Set is associated with a specific trigger table in Business Central and contains:

• One or more Business Rules (validation lines)

• Each Business Rule contains Scenarios and Conditions

• Each Condition can have Actions attached

Key Characteristics of Validation Sets:

• Trigger Table: Determines which table activates the rules

• Trigger Types: Defines which operations (Insert, Modify, Delete) activate the rules

• Enable Status: Master on/off switch for the entire Validation Set

• Rule Group Assignment: Controls which users are subject to the rules

Validation Sets provide organizational structure that makes your business rules:

• Easier to understand (related rules grouped together)

• Easier to test (activate/deactivate entire groups)

• Easier to maintain (common configuration shared across rules)

• More performant (QUALIA Rule Engine optimizes execution of related rules)

3.3 Creating Your First Validation Set

Let's walk through creating a simple Validation Set to understand the basic configuration process.

Step 1: Create a New Validation Set

1. Search for "Business Rules" and open the Business Rules list page

2. Select New from the action bar

3. Business Central opens the Business Rule Card page in create mode

Step 2: Configure Basic Properties

Fill in the General tab fields:

Code: Enter a unique identifier following your naming convention

• Example: SALES-QTYCHECK

• Use descriptive prefixes for functional area

• Keep it short but meaningful

Name: Enter a display name for list views

• Example: Sales Quantity Validation

Description: Enter detailed explanation of purpose

• Example: Prevents negative quantities on sales lines and validates quantity thresholds

Enable: Leave unchecked initially

• You'll enable after testing is complete

Step 3: Select Trigger Table

In the Trigger Table field, specify which Business Central table will activate these rules.

For our example, to validate sales line quantities, select:

• Trigger Table: 37 (Sales Line)

You can use the lookup (dropdown arrow) to search for tables by name or number.

Step 4: Configure Trigger Types

Select which database operations should activate the rules:

For quantity validation, select:

• ☑️ Trigger Insert: Validate when new sales lines are created

• ☑️ Trigger Modify: Validate when existing sales lines are modified

• ☐ Trigger Delete: Not needed for quantity validation

Step 5: Save the Validation Set

Select OK or use Ctrl+Enter to save the Validation Set. You now have a container ready for Business Rules (validation lines), but haven't yet defined any actual rules.

The next step would be to add Business Rules with Scenarios, Conditions, and Actions—which is covered in detail in Section 4 (Core Concepts) and Section 5 (Tutorial).

3.4 Configuring Trigger Tables

The Trigger Table determines which Business Central table your rules apply to. Selecting the correct trigger table is fundamental to creating effective business rules.

Understanding Trigger Table Selection

The trigger table should be the table where:

• The data you want to validate resides

• The business event you want to react to occurs

• Your rule formulas will primarily reference fields

Common Trigger Tables and Their Use Cases

💡 BC Consultant Tip: Choose the trigger table based on where users will encounter the validation. If you want to validate customer credit limits when users create sales orders, trigger on Sales Header (36) because that's where users enter order information. If you want to validate item availability when users add line items, trigger on Sales Line (37) because that's where item and quantity are entered.

Accessing Related Data via Linked Tables

If your validation requires data from tables other than the trigger table, you don't need to change the trigger table—instead, you configure Linked Tables (covered in Section 18). For example:

• Trigger Table: Sales Header (36)

• Linked Table: Customer (18) - to access credit limit information

• Your rule can now validate order amount against customer credit limit

This architecture allows you to keep the trigger table focused on where the business event occurs while still accessing all necessary data for validation.

3.5 Understanding Trigger Types

Trigger Types determine which database operations will activate your business rules. QUALIA Rule Engine supports three trigger types, each corresponding to a specific database operation.

Before Insert (Trigger Insert)

Executes after a user has entered data for a new record but before the record is saved to the database.

When to Use:

• Validate data before allowing record creation

• Set default values automatically

• Calculate values before commit

• Prevent invalid records from being created

Example: Validate that a new sales line has a positive quantity before allowing the line to be saved.

⚠️ CRITICAL: If a Before Insert rule displays an error message, the insert operation is cancelled and the record is not saved.

Before Modify (Trigger Modify)

Executes after a user has changed data in an existing record but before the changes are saved to the database.

When to Use:

• Validate changes before allowing them to be saved

• Compare old values with new values to detect specific changes

• Enforce business policies on modifications

• Require approval for certain types of changes

Example: Validate that modifying an order amount doesn't exceed customer credit limit before allowing the modification.

⚠️ CRITICAL: If a Before Modify rule displays an error message, the modify operation is cancelled and the changes are not saved.

Before Delete (Trigger Delete)

Executes when a user attempts to delete a record but before the record is actually removed from the database.

When to Use:

• Prevent deletion of records that have dependencies

• Check if related records exist that would be affected

• Implement permission-based deletion restrictions

• Require manager approval before deletion

Example: Prevent deletion of a customer record if the customer has open sales orders.

⚠️ CRITICAL: If a Before Delete rule displays an error message, the delete operation is cancelled and the record is not removed.

After Triggers - Why They're Not Included

You may notice that QUALIA Rule Engine only implements Before triggers (Before Insert, Before Modify, Before Delete), not After triggers (After Insert, After Modify, After Delete).

Reason: After triggers execute after the database transaction has already committed. At this point:

• The record is already saved/modified/deleted

• You cannot prevent the operation (it's already done)

• Displaying an error message would be confusing (the operation succeeded)

• Rolling back the transaction is not possible

What After Triggers Are Good For (and why QUALIA Rule Engine doesn't need them):

• Notifications (QUALIA Rule Engine's Notification actions work on Before triggers)

• Logging (QUALIA Rule Engine's Validation Log automatically logs all executions)

• Triggering workflows (QUALIA Rule Engine's Power Automate actions work on Before triggers)

💡 BC Consultant Tip: Because QUALIA Rule Engine uses Before triggers, your actions execute before the transaction commits. This means:

• Error actions effectively prevent invalid data from being saved

• Your users see validation errors before bad data enters the database

• You can use old value placeholders {TableID:FieldID} to compare before/after values

• All your action types work in a context where you can still influence the transaction

Configuring Multiple Trigger Types

You can select multiple trigger types for a single Validation Set. This is common when the same validation logic should apply to multiple operations.

Example: Credit Limit Validation

For a credit limit check, you typically want:

• ☑️ Trigger Insert: Validate when creating new sales orders

• ☑️ Trigger Modify: Validate when modifying existing orders (if amount increases)

• ☐ Trigger Delete: Not relevant for credit limits

By selecting both Insert and Modify, you ensure credit limits are enforced consistently regardless of which operation triggers the rules.

3.6 Enable/Disable Controls

QUALIA Rule Engine provides multiple levels of enable/disable controls, allowing you to activate or deactivate rules at different granularity levels.

Global Enable (Business Rule Setup)

Location: Business Rule Setup page, Enable checkbox

Effect: Master switch for the entire QUALIA Rule Engine system

• When Enabled: All active Validation Sets execute according to their configuration

• When Disabled: No business rules execute anywhere in the system, regardless of individual rule set activation status

Use Cases:

• System maintenance windows where rules should be suspended

• Troubleshooting to determine if rules are causing issues

• Data migration scenarios where validation should be bypassed temporarily

⚠️ WARNING: The global Enable checkbox overrides all other activation settings. Even if individual Validation Sets are marked as active, they will not execute if the global Enable is turned off.

Validation Set Enable (Business Rule Card)

Location: Business Rule Card page, General tab, Enable checkbox

Effect: Controls whether this specific Validation Set is active

• When Enabled: This Validation Set executes when trigger conditions are met (assuming global Enable is also on)

• When Disabled: This Validation Set does not execute, but other Validation Sets continue to work normally

Use Cases:

• Activating new rules after testing

• Temporarily suspending specific rules without deleting them

• Seasonal rules that only apply during certain periods

• Testing by selectively enabling/disabling rule sets

💡 BC Consultant Tip: Use the Validation Set Enable checkbox for normal rule activation management. Leave the global Enable in Business Rule Setup enabled unless you need to suspend ALL rules system-wide.

Business Rule Enable (Individual Validation Lines)

Location: Within a Validation Set, each Business Rule (validation line) has its own Enable checkbox

Effect: Controls whether this specific Business Rule is active within its Validation Set

• When Enabled: This Business Rule executes when the Validation Set processes (assuming both the Validation Set and global Enable are on)

• When Disabled: This Business Rule is skipped, but other Business Rules in the same Validation Set continue to execute

Use Cases:

• Testing individual rules within a Validation Set

• Temporarily disabling specific conditions without removing them

• Gradual rollout of rules (enable one at a time)

• A/B testing different validation approaches

Hierarchy of Enable Controls

For a Business Rule to execute, ALL three levels must be enabled:

1. ✅ Global Enable (Business Rule Setup) = ON

2. ✅ Validation Set Enable (Business Rule Card) = ON

3. ✅ Business Rule Enable (Individual validation line) = ON

If ANY level is disabled, the rule does not execute.

Example Scenarios:

3.7 Testing Your Configuration

After creating a Validation Set and configuring its basic properties, you should test the configuration before adding Business Rules (validation lines) to verify that:

• The Validation Set is recognized by the system

• The trigger table configuration is correct

• The enable controls work as expected

Test Procedure:

Step 1: Verify Validation Set Appears in List

1. Open the Business Rules list page

2. Locate your new Validation Set in the list

3. Confirm the Code, Name, Trigger Table, and Enable status are correct

Step 2: Test Enable/Disable Toggle

1. Select your Validation Set in the list

2. Use the Enable action to activate it

3. Verify the Enable column shows a checkmark

4. Use the Disable action to deactivate it

5. Verify the Enable column shows blank/unchecked

This confirms the enable control is working properly.

Step 3: Open for Editing

1. Select your Validation Set in the list

2. Select Edit or double-click the row

3. Verify the Business Rule Card opens correctly

4. Verify all fields show the values you configured

Step 4: Check Global Enable Status

1. Search for "Business Rule Setup"

2. Verify the global Enable checkbox is selected

3. If it's not selected, select it now (requires admin permissions)

Step 5: Verify in Extension Management

1. Search for "Extension Management"

2. Locate "QUALIA Rule Engine" in the list of installed extensions

3. Verify it shows as installed and enabled

4. Note the version number (should be 1.1.0.4 or later)

Next Steps After Testing Configuration:

Once you've verified the Validation Set configuration is correct:

1. Add Business Rules: Create individual validation lines within the Validation Set (covered in Section 4)

2. Define Scenarios and Conditions: Configure the actual business logic (covered in Sections 4-5)

3. Attach Actions: Specify what happens when conditions are met (covered in Sections 7-17)

4. Test with Real Data: Use the Validation Log to monitor execution (covered in Section 6)

💡 BC Consultant Tip: Always create and test Validation Sets in a sandbox environment first. Only after thorough testing should you move them to production. This prevents disrupting live business operations with rules that may have unintended consequences.