Email Actions

Email Actions (Action Type 5) automatically send email messages to specified recipients when business rules execute. This powerful capability enables automated notifications to managers, departments, or external parties without requiring manual intervention. This section explains how to configure email actions, how to specify recipients, and best practices for automated email notifications.

11.1 When to Use Email Actions

Email actions are appropriate when business events should trigger notifications to stakeholders who are not necessarily working in Business Central at the time the event occurs.

Appropriate Use Cases: Manager notifications for approval-required transactions, department alerts for high-value orders, vendor notifications for purchase orders, customer service notifications for special handling requirements, compliance reporting for audit trail requirements, automated escalation workflows.

Immediate Response Requirements: Email is an asynchronous communication mechanism. If the notification requires immediate action or response from the recipient before the transaction can proceed, consider using Confirmation actions or manual approval workflows rather than email actions.

Confidential or Sensitive Information: Email is generally not a secure communication channel. If the business rule would send highly confidential information (for example, detailed financial data, personal information subject to privacy regulations, or proprietary business intelligence), ensure that your organization's email infrastructure provides appropriate security, or consider alternative notification mechanisms.

11.2 Prerequisites for Email Actions

Before email actions can function, several configuration requirements must be met at both the Business Central system level and the QUALIA Rule Engine level.

System-Level Prerequisites

SMTP Configuration in Business Central: Business Central must be configured with a valid SMTP server connection. This configuration is typically performed by system administrators and includes:

• SMTP server address (for example, smtp.office365.com)

• Port number (typically 587 for TLS or 25 for standard SMTP)

• Authentication credentials (username and password for the sending email account)

• Encryption settings (TLS/SSL configuration)

• From address (the email address that will appear as the sender)

Without proper SMTP configuration, Business Central cannot send emails, and email actions will fail silently without preventing transactions from completing.

Email Account Permissions: The email account used for SMTP authentication must have appropriate permissions to send email on behalf of your organization. Some email systems (for example, Microsoft 365) require explicit configuration to allow applications to send email through the account.

Network Connectivity: Business Central Server must have network connectivity to the SMTP server. Firewall rules may need to be configured to allow outbound SMTP traffic on the required port.

QUALIA Rule Engine Prerequisites

Permission Set Assignment: Users or user groups must be assigned the QUA Email Notification UnLicensed permission set. This permission set grants the necessary permissions to execute email actions. Without this permission set, email actions will not execute even if the business rule is configured correctly.

Email Action Configuration: The business rule must include an Email action with properly configured recipient addresses, subject line, and message body. Incomplete email configuration will result in email delivery failures.

11.3 Configuring Email Actions Step by Step

This section provides detailed instructions for creating and configuring Email actions within your business rules.

Step 1: Create or Open the Business Rule

1. Navigate to the Business Rules page in Business Central

2. Open the Business Rule Set that should send email notifications

3. Create a new Business Rule or open an existing rule that requires email notification

4. Configure the Condition that determines when the email should be sent

The condition should evaluate to TRUE when the business event requiring notification occurs. For example, if you want to notify a manager when order amounts exceed $10,000, the condition would be [36:61] is >10000.

Step 2: Add a New Email Action

1. In the Actions section of the Business Rule, create a new action line

2. Set the Action Type field to Email (this is Action Type 5 in the enum)

3. The new action line is now configured to send an email when the condition evaluates to TRUE

Step 3: Configure Email Recipients

1. In the action line, locate the Action Code or Email ID field

2. Enter a new code (for example, EMAIL001) or select an existing email configuration

3. Open the Email Detail card by selecting the Action Code field

4. On the Email Detail card, configure recipient addresses:

To Field: Primary recipients who should receive the email. Multiple addresses can be separated by semicolons (for example, manager@company.com; director@company.com).

Cc Field: Carbon copy recipients who should be aware of the notification but are not primary recipients.

Bcc Field: Blind carbon copy recipients who receive the email without other recipients being aware. Useful for audit trails or compliance documentation.

Step 4: Configure Email Subject Line

1. Locate the Subject field on the Email Detail card

2. Enter a descriptive subject line that clearly identifies the notification purpose

3. Use placeholder syntax to include dynamic values in the subject line

Example Subject Lines:

• Static: "Manager Approval Required for High-Value Order"

• Dynamic: "Sales Order [36:3] Exceeds Approval Threshold"

• Descriptive: "URGENT: Customer [18:2] Credit Limit Exceeded on Order [36:3]"

Step 5: Configure Email Message Body

1. Locate the Email Body or Message field on the Email Detail card

2. Enter the email message content

3. Use placeholder syntax to include dynamic field values

4. Structure the message with clear paragraphs and appropriate formatting

Example Email Body:

A high-value sales order has been created and requires your approval.

Order Details:
- Order Number: [36:3]
- Customer: [36:79]
- Order Amount: [36:61]
- Order Date: [36:20]
- Salesperson: [36:29]

This order exceeds the standard approval threshold of $10,000. Please review the order in Business Central and approve or reject it according to company policy.

To review the order, search for Sales Order [36:3]

Step 6: Save and Test

1. Save the Email Detail card

2. Save the Business Rule

3. Test the configuration in a sandbox environment by creating a transaction that meets the condition

4. Verify that the email is sent to the correct recipients

5. Verify that placeholder values are correctly substituted

6. Verify that the email content is clear and professional

11.4 Dynamic Recipient Addresses Using Placeholders

One of the most powerful capabilities of Email actions is the ability to dynamically determine recipient addresses based on field values in the transaction. This enables targeted notifications to the appropriate stakeholders without requiring hardcoded email addresses.

Using Field Placeholders for Recipient Addresses

If a field in Business Central contains an email address, you can use placeholder syntax to send email to that address:

Example: Send Email to Customer

Configuration:

• Trigger Table: 36 (Sales Header)

• Linked Table: 18 (Customer)

• Condition: [36:61] is >5000 (Order amount > $5,000)

• Email To: [18:102] (Customer.E-Mail field)

• Subject: "Thank you for your order [36:3]"

• Body: "Thank you for your order. We have received your order for [36:61] and will process it promptly."

This configuration sends a confirmation email directly to the customer's email address stored in their customer record.

Example: Send Email to Salesperson

Configuration:

• Trigger Table: 36 (Sales Header)

• Linked Table: 13 (Salesperson/Purchaser) using field 118 (Salesperson Code)

• Email To: [13:5] (Salesperson.E-Mail)

This sends email to the salesperson assigned to the order.

Combining Static and Dynamic Recipients

You can combine static email addresses with dynamic placeholders:

To Field: manager@company.com Cc Field: [18:102];[13:5] (Customer email; Salesperson email)

This sends the primary email to the manager, with copies to both the customer and the salesperson.

Handling Missing Email Addresses

If a placeholder references a field that is blank (for example, a customer record with no email address), the email will be sent to the other recipients but will not fail. However, be aware that if ALL recipient fields are blank, the email may fail to send.

Best Practice: Add a Scenario to your business rule to ensure the email address field is populated before attempting to send email:

Scenario: [18:102] is <>'' (Customer email is not blank)
Condition: [Order meets notification criteria]
Email Action: Send to [18:102]

If the customer email is blank, the Scenario filter does NOT match (blank is not <>''), and the rule does not execute, avoiding email delivery failures.

11.5 Best Practices for Email Actions

Write Professional, Clear Subject Lines

Subject lines should immediately convey the notification purpose and priority:

✅ Good: "URGENT: Sales Order [36:3] Requires Immediate Approval" ✅ Good: "High Value Order Alert: Customer [18:2] - Amount [36:61]" ❌ Bad: "Notification" ❌ Bad: "Rule executed"

Structure Email Bodies for Readability

Use clear paragraphs, headings, and lists:

✅ Good:

Order Approval Required

A sales order exceeding approval thresholds requires your review:

Order Details:
- Order No.: [36:3]
- Customer: [36:79]
- Amount: [36:61]

❌ Bad:

Order [36:3] for [36:79] amount [36:61]

Include Actionable Information

Tell recipients exactly what they need to do:

✅ "To approve this order, open Sales Orders in Business Central, search for order number [36:3], and select Approve." ❌ "Please take appropriate action."

Avoid Email Overload

Do not send individual emails for every routine transaction. Consider:

• Sending emails only for exceptional situations (high values, errors, special requirements)

• Using batch summary emails instead of individual transaction emails

• Implementing threshold-based notifications rather than notifying for every transaction

Test Thoroughly Before Production

Email actions have the potential to send large volumes of email to customers, vendors, or executives. Always:

• Test in sandbox environment first

• Verify correct recipient addresses

• Verify placeholder substitution works correctly

• Verify email content is professional and accurate

• Start with small pilot user groups before enabling globally