Interactive Confirmation Dialogs in Business Rules

Introduction

Business processes often require user confirmation before executing critical operations, particularly for irreversible actions, high-value transactions, or operations with significant downstream impacts. Lack of confirmation mechanisms leads to accidental data modifications, unauthorized transactions, and user errors that require correction through manual data fixes or transaction reversals.

Confirmation requirements typically arise in deletion operations (removing master data records, canceling pending transactions), high-value transactions (orders exceeding thresholds, payments above limits), policy violations (overriding credit limits, bypassing standard procedures), and data modifications (changing critical fields, bulk updates affecting multiple records).

QUALIA Rule Engine's Confirmation actions enable interactive user prompts requiring explicit approval before proceeding with operations. Confirmation dialogs support custom messaging (explaining what requires confirmation and why), conditional presentation (showing confirmations only when specific conditions met), Yes/No branching (different actions based on user response), and operation blocking (preventing action completion if user declines).

Confirmation action capabilities:

• Custom confirmation messages with dynamic content

• Field value incorporation in prompts

• Yes/No response handling with conditional actions

• Operation blocking on negative responses

• Chained confirmations for multi-step approval

• Audit trail of user responses

Part 1: Basic Confirmation Configuration

Simple Yes/No Confirmation

Basic confirmation dialog with static message demonstrates core confirmation action structure.

Validation Set: Customer - Delete Confirmation - OnDelete

Rule 1: Confirm Customer Deletion

Table: Customer (18)

Condition:

Action - Confirmation:

Result: User must explicitly confirm customer deletion before record removed.

Confirmation with Context

Rule 2: Confirm with Customer Details

Condition:

Action - Confirmation:

Message: 
Confirm customer deletion:

Customer No.: [18:1]
Name: [18:2]
Balance: $[18:62]

Result: User sees customer details before confirming deletion.

Part 2: Conditional Confirmations

Confirming Based on Conditions

Confirmations can be presented selectively based on business logic rather than for every transaction.

Validation Set: Sales Order - Large Order Confirmation - OnRelease

Rule 1: Confirm High-Value Orders

Table: Sales Header (36)

Condition:

[36:109]

Action - Confirmation:

Message:
This order exceeds the standard order limit.

Order No.: [36:3]
Customer: [36:79]
Amount: $[36:109]

Result: Only high-value orders trigger confirmation prompt.

Credit Limit Override Confirmation

Rule 2: Confirm Credit Limit Violation

Validation Set: Sales Order - Credit Check - OnRelease

Source References:

1. Customer (18)
   Link via: [36:2] = [18:1]

2. Customer Ledger Entry (21)
   Link via: [18:1] = [21:3]
   Reference Filters:
     [21:13]

Condition:

SUM(21:14) + [36:109] > [18:59]

Action - Confirmation:

Message:
CREDIT LIMIT EXCEEDED

Customer: [18:2]
Credit Limit: $[18:59]
Current Balance: $[SUM(21:14)]
This Order: $[36:109]
Total Exposure: $[SUM(21:14) + [36:109]]
Over Limit: $[SUM(21:14) + [36:109] - [18:59]]

Proceeding will exceed customer credit limit.

Do you have authorization to override credit limit?

If Yes: 
  - Allow release
  - Set [36:CustomCreditOverride] = true
  - Set [36:CustomCreditOverrideUser] = [CurrentUser]
  - Set [36:CustomCreditOverrideDate] = [T]

Result: Credit limit violations require explicit authorization with audit trail.

Part 3: Branched Actions Based on Response

Different Actions for Yes/No

Confirmation responses can trigger different business logic based on user choice.

Validation Set: Sales Order - Pricing Override - OnModify

Rule 1: Confirm Below-Cost Pricing

Source References:

1. Sales Line (37)
   Link via: [36:3] = [37:3]

2. Item (27)
   Link via: [37:6] = [27:1]

Condition:

[37:22] < [27:22]

Action - Confirmation:

Message:
BELOW-COST PRICING DETECTED

Item: [37:6] - [37:11]
Unit Cost: $[27:22]
Unit Price: $[37:22]
Loss per Unit: $[27:22 - [37:22]]
Quantity: [37:15]
Total Loss: $[[27:22 - [37:22]] * [37:15]]

Selling below cost results in loss on this line.

Do you have approval for below-cost pricing?

If Yes:
  - Allow pricing
  - Set [37:CustomPriceOverride] = true
  - Set [37:CustomPriceOverrideReason] = 'Below Cost Approved'
  - Send Email to finance.manager@company.com:
      Subject: Below-Cost Sale Approved - Order [36:3]
      Body: Below-cost pricing approved by [CurrentUser] on [T]

If No:
  - Reset [37:22] = [27:22]

Result: Below-cost pricing requires approval or automatic reset to cost.

Cascading Confirmations

Rule 2: Multi-Step Approval Process

Validation Set: Item - Cost Change Confirmation - OnModify

Condition:

{27:22} <> [27:22]
AND [27:22]

Action - Confirmation 1:

Message:
SIGNIFICANT COST INCREASE

Item: [27:1] - [27:3]
Previous Cost: ${27:22}
New Cost: $[27:22]
Increase: $[27:22 - {27:22}]
Percentage: [[27:22 / {27:22} - 1] * 100]%

Cost increase exceeds 20% threshold.

Confirm cost change?

If Yes: Proceed to Confirmation 2
If No: 
  - Revert [27:22]

Action - Confirmation 2 (if Confirmation 1 = Yes):

Message:
PRICE UPDATE RECOMMENDATION

Item cost has increased significantly.

Current Selling Price: $[27:27]
New Cost: $[27:22]
Current Margin: [[27:27 - [27:22]] / [27:27] * 100]%

Recommended new price to maintain margin: $[27:22 / (1 - 0.25)]
(25% margin target)

Update selling price now?

If Yes:
  - Set [27:27] = [27:22 / (1 - 0.25)]

Result: Cost increase confirmation followed by optional price adjustment.

Part 4: Confirmations with Field Updates

Tracking Confirmation Responses

Confirmation actions can update fields to create audit trails of user decisions.

Validation Set: Purchase Order - Expedite Fee Confirmation - OnModify

Rule 1: Confirm Expedite Charges

Table: Purchase Header (38)

Condition:

[38:CustomExpedite]

Action - Confirmation:

Message:
EXPEDITE FEES APPLY

Marking this order as expedited will incur additional charges.

Order No.: [38:3]
Vendor: [38:79]
Estimated Expedite Fee: $[38:91 * 0.15]
(15% of order value)

Approve expedite fee?

If Yes:
  - Allow expedite flag
  - Set [38:CustomExpediteFee] = [38:91 * 0.15]
  - Set [38:CustomExpediteApprovedBy] = [CurrentUser]
  - Set [38:CustomExpediteApprovedDate] = [T]
  - Add to [38:91] the expedite fee amount
  - Show message "Expedite fee added to order total."

If No:
  - Revert [38:CustomExpedite]

Result: Expedite approval tracked with user, date, and automatic fee calculation.

Status Field Management

Rule 2: Exception Status Confirmation

Validation Set: Sales Order - Hold Status - OnModify

Condition:

[36:CustomStatus]

Action - Confirmation:

Message:
PLACE ORDER ON HOLD?

Order: [36:3]
Customer: [36:79]
Amount: $[36:109]

Placing order on hold will:
- Stop all processing
- Block shipment
- Require manager release

Reason for hold required.

[Input box for hold reason]

Continue with hold status?

If Yes:
  - Set [36:CustomStatus] = 'On Hold'
  - Set [36:CustomHoldReason] = [User input]
  - Set [36:CustomHoldDate] = [T]
  - Set [36:CustomHoldUser] = [CurrentUser]
  - Send Email to sales.manager@company.com:
      Subject: Order [36:3] Placed on Hold
      Body: Order on hold by [CurrentUser]. Reason: [User input]

If No:
  - Revert [36:CustomStatus]

Result: Hold status requires explicit confirmation and documented reason.

Part 5: Validation Blocking Confirmations

Preventing Invalid Operations

Confirmations can absolutely block operations when conditions unsafe or unauthorized.

Validation Set: Item - Negative Inventory Check - OnPost

Rule 1: Block Negative Inventory Sales

Table: Item Ledger Entry (32)

Condition:

[32:7] is 'Sale'
AND [Item:Inventory] - [32:8]

Action - Confirmation:

Message:
INSUFFICIENT INVENTORY

Item: [32:5] - [Item:3]
Current Inventory: [Item:Inventory]
Sale Quantity: [32:8]
Shortage: [[Item:Inventory] - [32:8]] * -1

This sale would create negative inventory.

Options:
1. Cancel this sale
2. Proceed anyway (requires authorization)

Proceed with negative inventory?

If Yes (requires specific permission):
  - Check if [CurrentUser] in [AuthorizedNegativeInventoryUsers]
  - If authorized:
      Allow posting
      Set [Item:CustomNegativeInventoryFlag]

Result: Negative inventory prevented unless specifically authorized.

Regulatory Compliance Confirmations

Rule 2: Export Compliance Check

Validation Set: Sales Order - Export Restriction - OnRelease

Condition:

[Customer:CustomCountryCode]

Action - Confirmation:

Message:
EXPORT RESTRICTION WARNING

Customer Country: [Customer:CustomCountryCode]
This country requires export compliance verification.

BEFORE PROCEEDING:
☐ Export license obtained
☐ Product eligibility confirmed
☐ End-user certification received
☐ Compliance officer approval

Have all export compliance requirements been satisfied?

If Yes:
  - Show message "Enter export license number:"
  - Set [36:CustomExportLicense] = [User input]
  - Set [36:CustomExportCompliance] = true
  - Set [36:CustomComplianceOfficer] = [CurrentUser]

Result: Export orders blocked without documented compliance verification.

Part 6: User Experience Best Practices

Message Design Guidelines

Clear, concise messaging:

Structured information:

Action Clarity

Explicit consequences:

Clear button options:

Confirmation Frequency

Avoid confirmation fatigue:

Use thresholds appropriately:

Part 7: Testing and Implementation

Testing Checklist

Before deploying confirmation actions:

• Test Yes response (operation proceeds correctly)

• Test No response (operation blocked correctly)

• Verify field updates execute on Yes response

• Confirm field reverts execute on No response

• Test with null/empty field values

• Verify conditional confirmations appear only when appropriate

• Check cascading confirmations in sequence

• Confirm email notifications send correctly

• Test with various user permissions

• Verify message formatting and readability

• Test blocking confirmations prevent operations

• Validate audit trail fields populate correctly

Performance Considerations

Optimize confirmation conditions:

✓ Good: Specific conditions
  [36:109]

Minimize confirmation chains:

Common Patterns

Pattern 1: Deletion Protection

Pattern 2: Threshold Approval

Pattern 3: Policy Override

Summary and Key Takeaways

This guide covered interactive confirmation dialogs using QUALIA Confirmation actions in Microsoft Dynamics 365 Business Central:

• Basic confirmations requiring explicit user approval for operations

• Conditional confirmations presented only when specific conditions met

• Branched actions executing different logic based on Yes/No responses

• Field updates creating audit trails of confirmation decisions

• Blocking confirmations preventing unauthorized or unsafe operations

• UX best practices for clear messaging and appropriate confirmation frequency

Practical applications:

• Deletion protection for master data records

• High-value transaction approvals

• Credit limit override authorization

• Policy violation confirmations

• Regulatory compliance verification

• Cost and pricing change approvals

Implementation exercise: Create a credit limit override system:

1. Identify credit limit threshold conditions

2. Design confirmation message with exposure details

3. Configure Yes branch (update override fields, send notification)

4. Configure No branch (block order, display message)

5. Test with various customer credit scenarios

6. Monitor override frequency and patterns

Related topics:

• Blog 026: Assign Actions (field updates in confirmation branches)

• Blog 027: Email Notifications (notifications from confirmation responses)

• Blog 029: Custom Validation Messages (blocking messages vs. confirmations)

• Blog 030: Understanding Scenarios (confirmation timing and triggers)

This blog is part of the QUALIA Rule Engine series for Microsoft Dynamics 365 Business Central. Follow along as we explore business rule automation patterns.