Message Actions

Message Actions (Action Type 2) display informational messages to users without blocking transactions. Unlike Error Message actions that prevent records from being saved, Message actions show information and then allow the transaction to proceed normally. This section explains when to use Message actions, how to configure them effectively, and best practices for creating clear, helpful user messages.

7.1 When to Use Message Actions

Message Actions are appropriate when you want to inform users about something important without preventing them from completing their work. The key characteristic of Message actions is that they are non-blocking: after users acknowledge the message by clicking OK, the transaction continues and the record is saved successfully.

Appropriate Use Cases for Message Actions

Informational Notifications: Use Message actions to inform users about conditions or events that they should be aware of but that do not require preventing the transaction. For example, you might display a message informing the user that their action triggered an automated email notification to a manager, or that a related process will execute automatically in the background.

Policy Reminders: Display messages that remind users of organizational policies or procedures that apply to the current transaction without enforcing those policies through validation. For example, when a sales order exceeds a certain threshold, display a message reminding the user that they should obtain verbal approval from their manager before processing the order, but do not prevent them from entering the order if they choose to proceed.

Status Alerts: Inform users about the status of related records or conditions that might affect how they should handle the current transaction. For example, when creating a sales order for a customer, display a message if that customer has overdue invoices, without preventing the new order from being created.

Process Guidance: Provide users with helpful information about what will happen next or what additional steps they should take after completing the current transaction. For example, after creating a purchase order for a new vendor, display a message reminding the user that they need to complete the vendor certification process separately.

Confirmation of Automated Actions: Inform users that the system has automatically performed actions in response to their transaction. For example, display a message confirming that inventory has been reserved, that an email has been sent to the shipping department, or that a workflow approval request has been generated.

When NOT to Use Message Actions

Data Validation Failures: Do not use Message actions for data validation errors. If data is invalid and should not be saved, use Error Message actions (Action Type 1) instead. Message actions allow invalid data to be saved, which defeats the purpose of validation.

Critical Compliance Requirements: Do not use Message actions to notify users about compliance violations if those violations must be prevented. Use Error Message actions to enforce compliance requirements.

Information That Users Will Ignore: Message actions interrupt the user's workflow by displaying a modal dialog box that requires acknowledgment. If users will encounter the same message repeatedly and it does not provide value, they will quickly learn to click OK without reading it. Reserve Message actions for truly important information.

7.2 Configuring Message Actions Step by Step

Configuring a Message action involves creating the action record, specifying the action type, and defining the message text that users will see.

Step 1: Create the Business Rule with Condition

Before you can add a Message action, you must have a Business Rule with at least one Condition configured. The Message action will execute when that condition evaluates to TRUE.

1. Open your Business Rule Set for editing

2. Navigate to the Rules tab

3. Create or select the Business Rule (validation line) that should trigger the message

4. Configure the validation condition that determines when the message should appear

Step 2: Add a New Action

From the Quick Rule Card page or the Actions section:

1. Locate the Actions section (this displays actions for the currently selected condition)

2. Create a new action line by clicking in the Actions area or selecting New Action

3. Business Central creates a blank action line ready for configuration

Step 3: Set the Action Type to Message

Each action must have an Action Type that determines what the action does:

1. Locate the Action Type field in the action line

2. Click in the field to display the dropdown list of available action types

3. Select Message from the list (this is Action Type 2 in the enum)

4. The action is now configured as a Message action

Step 4: Configure the Message Details

After setting the Action Type to Message, you need to specify what message text users will see:

1. Locate the Action Code or Detail ID field in the action line

2. If a message detail record already exists that contains the text you want to use, you can select its ID from the lookup

3. To create a new message, enter a new ID number or leave blank if using automatic number series

4. Select the Action Code field or use the drill-down action to open the Message Detail card

5. Business Central opens a detail page where you can configure the complete message

Step 5: Enter the Message Text

On the Message Detail card:

1. Locate the Message field (this is typically a large text box that allows multiple lines of text)

2. Enter the complete message text that users will see when the action executes

3. Write the message clearly and professionally (see Section 7.5 for best practices)

4. You can include placeholder syntax in the message text to display dynamic field values (see Section 7.3)

5. Save the Message Detail card

Step 6: Configure Action Priority (Optional)

If this condition has multiple actions, you can control the execution order:

1. Locate the Action Priority or Sequence field in the action line

2. Enter a numeric value that determines execution order (lower numbers execute first)

3. If you do not specify priority, actions execute in the order they appear

Step 7: Save and Test

1. Save the Business Rule Set

2. Enable the Business Rule Set if it is not already active

3. Perform a test transaction that should trigger the condition

4. Verify that the message displays correctly with appropriate text

5. Verify that after clicking OK, the transaction proceeds and the record saves successfully

7.3 Using Placeholders in Message Text for Dynamic Content

One of the most powerful features of Message actions is the ability to include dynamic content using placeholder syntax. Placeholders are replaced with actual field values at runtime, allowing you to create messages that reference specific data from the current transaction.

Basic Placeholder Syntax

Placeholders in message text use square bracket notation: [TableID:FieldID]

Example Message with Placeholders:

"You are creating a sales order for customer [36:2] with total amount [36:61]

When this message displays to users, QUALIA Rule Engine replaces the placeholders with actual values:

Common Placeholder Patterns for Messages

Displaying the Current Value:

"The quantity you entered is [37:15]

Displaying Related Table Values via Linked Tables: If you have configured a Linked Table to Customer, you can reference customer fields:

"Customer [18:2] has current balance of [18:59] and credit limit of [18:20]

Displaying Calculated Values: Use curly braces {} for calculations:

"Total order value is {[37:15] * [37:22]

Displaying System Information:

"This order was created by user [USERID] on [TODAY]

Best Practices for Placeholders in Messages

Include Context Around Placeholder Values: Do not just display the raw field value—provide context that explains what the value represents.

❌ Bad: "Value: [37:15]"
✅ Good: "The quantity you entered is [37:15] units."

Use Field Labels, Not Technical Names: Write messages as if placeholders will be replaced with values, using business terminology.

❌ Bad: "Field 15 = [37:15]"
✅ Good: "Quantity: [37:15]"

Test Placeholder Resolution: Always test messages with placeholders to verify they resolve correctly and display meaningful values.

Consider Field Formats: Some fields display with specific formatting (dates, decimals, etc.). Verify the displayed format is appropriate for your message.

7.4 Message vs. Error: Choosing the Right Action Type

A common question when configuring business rules is whether to use a Message action (non-blocking) or an Error Message action (blocking). The decision depends on whether the condition represents a policy that must be enforced or merely information that should be communicated.

Use Error Message Actions (Action Type 1) When:

Data Must Be Prevented: The condition detects data that is invalid, violates business rules, or creates data integrity problems. If allowing the data to be saved would cause errors in downstream processes or violate compliance requirements, use Error Message actions.

Policy Enforcement is Required: The condition detects a policy violation that absolutely must be prevented, not just discouraged. Policies that are regulatory requirements, financial controls, or critical business rules should use Error actions.

Transaction Must Be Stopped: The condition detects a state where allowing the transaction to proceed would cause significant problems that cannot be easily corrected later.

Examples Where Error Actions Are Appropriate:

• Negative quantities on sales lines (causes inventory processing failures)

• Required fields left blank (violates database constraints or business logic)

• Exceeding hard credit limits (violates financial controls)

• Transactions that would violate regulatory compliance requirements

Use Message Actions (Action Type 2) When:

Information Should Be Communicated: The condition detects something users should know about, but the transaction is still valid and can proceed safely.

Policy Is Advisory, Not Mandatory: The condition relates to a best practice or recommended procedure, but users may have legitimate reasons to proceed anyway.

User Discretion Is Appropriate: The condition suggests that users should take additional action or exercise caution, but you trust users to make appropriate decisions.

Post-Transaction Actions Are Needed: The condition informs users about additional steps they should take after completing the current transaction.

Examples Where Message Actions Are Appropriate:

• Customer has overdue invoices, but new orders are still permitted

• Order exceeds typical size thresholds (informational, not blocking)

• Vendor setup is incomplete but purchase orders can still be created

• Automatic processes have been triggered (confirmation messages)

The Middle Ground: Confirmation Actions

If you are unsure whether to use Message or Error, consider using Confirmation actions (Action Type 3) instead. Confirmation actions display a Yes/No dialog that allows users to choose whether to proceed, giving users the ability to override the policy while creating a conscious decision point.

7.5 Best Practices for Writing Effective User Messages

The quality of your message text significantly impacts how users perceive and respond to business rules. Well-written messages provide clear guidance and maintain user productivity. Poorly written messages frustrate users and reduce confidence in the system.

Characteristics of Effective Messages

Clear and Specific: State exactly what condition was detected and why users are seeing the message.

❌ Vague: "Please be aware of the customer status."
✅ Clear: "This customer has 3 overdue invoices totaling 2,500.00. Please verify payment arrangements before processing this order."

Actionable: Tell users what they should do with the information, if any action is needed.

❌ Non-actionable: "High value order detected."
✅ Actionable: "This order exceeds 10,000.00. Please obtain verbal approval from your department manager before submitting for processing."

Professional Tone: Use complete sentences with proper grammar and punctuation. Avoid slang, abbreviations (except standard business terms), or overly casual language.

❌ Unprofessional: "Heads up! Big order!"
✅ Professional: "This order qualifies for special pricing review. The pricing team will be notified automatically."

Positive Framing: When possible, frame messages in terms of what users should do rather than what they did wrong.

❌ Negative: "You forgot to check the shipping requirements."
✅ Positive: "Please verify shipping requirements for international orders to ensure timely delivery."

Appropriate Length: Messages should be long enough to provide necessary information but concise enough that users will read them completely.

❌ Too brief: "Warning!"
❌ Too long: Multiple paragraphs of detailed explanation
✅ Appropriate: 1-3 sentences providing context and any needed action

Avoiding Common Message Writing Mistakes

Do Not Use Technical Jargon: Users are business professionals, not developers. Avoid technical terms like "trigger," "validation," "condition evaluated to true," etc.

Do Not Reference Technical Implementation: Do not mention table numbers, field IDs, or system internals.

❌ Technical: "Trigger field [37:15] exceeded threshold value in condition 1."
✅ Business-focused: "The quantity you entered exceeds normal ordering limits."

Do Not Overuse Messages: If users will see the same message repeatedly during normal work, they will stop reading it. Reserve messages for truly exceptional or noteworthy conditions.

Do Include Contact Information When Appropriate: If the message requires users to take action involving other people or departments, provide contact information.

✅ "Orders over 50,000.00 require CFO approval. Please contact the finance department at extension 4500."

7.6 Practical Examples of Message Actions

The following examples demonstrate common scenarios where Message actions provide value without blocking transactions.

Example 1: Customer Credit Status Notification

Business Requirement: When creating a sales order, inform users if the customer has exceeded 80% of their credit limit, but do not prevent the order.

Rule Configuration:

• Trigger Table: 36 (Sales Header)

• Trigger Type: Before Insert

• Linked Table: Customer (18) linked via Sell-to Customer No.

• Condition Formula: {[18:59] / [18:20]} is >=0.8 (Balance ÷ Credit Limit ≥ 80%)

• Action Type: Message

• Message Text: "Customer [18:2] is currently using [18:59] of their [18:20] credit limit (80% or more). Please verify payment terms and consider requiring payment before shipping this order."

Why Message, Not Error: Sales orders for customers approaching their credit limit may still be legitimate business—perhaps the customer will pay down their balance before the new order ships, or the sales manager may approve an exception. The message informs users of the situation so they can exercise appropriate judgment.

Example 2: Automated Process Notification

Business Requirement: When a purchase order is created with a new vendor (vendor created within last 30 days), inform the user that the vendor onboarding workflow has been triggered automatically.

Rule Configuration:

• Trigger Table: 38 (Purchase Header)

• Trigger Type: Before Insert

• Linked Table: Vendor (23) linked via Buy-from Vendor No.

• Scenario: [38:79] is '' (Document Status = blank, meaning not yet posted)

• Condition Formula: [23:50] is >={[TODAY] - 30} (Vendor Date Created is within last 30 days)

• Action Type: Message

• Message Text: "This purchase order is for vendor [23:2] who was added to the system recently. The vendor onboarding workflow has been triggered automatically. Please ensure all vendor certifications are complete before releasing this order for payment."

Why Message, Not Error: The purchase order itself is valid, and users are allowed to create purchase orders with new vendors. The message ensures users are aware of the new vendor status and reminds them of additional process steps.

Example 3: Shipping Method Reminder

Business Requirement: When a sales order line quantity exceeds 500 units, remind users that large shipments require freight shipping, but allow users to select their own shipping method.

Rule Configuration:

• Trigger Table: 37 (Sales Line)

• Trigger Type: Before Insert, Before Modify

• Trigger Field: [37:15] (Quantity field only)

• Condition Formula: [37:15] is >=500

• Action Type: Message

• Message Text: "You are ordering [37:15] units of item [37:6]. Quantities over 500 units typically require freight shipping rather than standard ground service. Please verify the shipping method is appropriate for this order size."

Why Message, Not Error: Users may have legitimate reasons to use standard shipping even for large quantities (for example, the customer is willing to accept multiple smaller shipments, or special arrangements have been made). The message provides guidance without enforcing a rigid rule.