Chapter 04 : Configuring Email Triggers and Rules

4.1 Understanding Email Triggers

Email triggers are the foundation of automated email notifications. A trigger defines when an email should send by specifying which Business Central table to monitor, which field changes to respond to, and what type of data change (insert, modify, or delete) should activate the email notification. Understanding how triggers work and how to configure them correctly is essential to creating email notifications that send at the right moment with the right context.

What Are Triggers?

In the context of the QUALIA Rule Engine and Advanced Email App, a trigger is a configuration that tells Business Central to execute your email notification whenever a specific data change occurs. Business Central's database operations go through a systematic process every time users create, modify, or delete records. At specific points in this process—before a record is inserted, after a field is modified, when a delete operation begins—the Rule Engine can intercept the operation and evaluate whether any configured business rules or email notifications should execute.

Think of triggers as watchers that monitor specific locations (tables) for specific events (field changes). When the event you've configured occurs, the trigger activates and tells the Rule Engine "something interesting just happened—check if you need to send an email about this." The Rule Engine then evaluates your email template configuration, including any scenario conditions you've defined, and determines whether to actually send the email.

This trigger-based approach ensures that email notifications send automatically and reliably without requiring users to remember to send notifications manually. Once you configure a trigger, Business Central handles the monitoring and execution automatically, sending emails consistently every time the specified conditions are met, regardless of who makes the data change or how busy your team is.

Insert, Modify, and Delete Events

Business Central recognizes three fundamental types of data operations, and email notifications can trigger on any of these operations:

Insert Events occur when users create new records in Business Central. For example, when a salesperson creates a new sales order, when a customer record is added to the system, when inventory items are created, or when any new data is entered into any table. Insert triggers are appropriate for "welcome" emails, "creation notification" emails, or any scenario where you need to respond to something new appearing in your system.

When you configure an insert trigger for an email, the notification sends when a new record is created. At the moment the trigger fires, the new record's data is available for use in placeholders, so you can include information from the new record in your email content. For example, an insert trigger on the Sales Header table can send an email containing the new order number, customer name, and order amount because all of these values are populated as part of creating the order.

Modify Events occur when users change existing records. For example, when someone updates a customer's credit limit, changes an order's status from Open to Released, modifies inventory quantities, or changes any field value in any existing record. Modify triggers are the most commonly used trigger type because many business processes are driven by status changes, approval state changes, or reaching specific threshold values that require notification.

When you configure a modify trigger, you specify which field to monitor. The email notification sends only when that specific field changes, not when other fields in the same record change. This field-level triggering granularity prevents emails from firing unnecessarily when irrelevant changes occur. For example, you can trigger an email when a sales order's status changes without sending emails every time someone modifies the order's ship-to address or adds a line item.

Delete Events occur when users remove records from Business Central. For example, when an order is deleted, when a customer record is removed, or when any record is deleted from any table. Delete triggers are less commonly used for email notifications (because deleted records often don't require notification), but they can be valuable for audit purposes, approval processes where deletion requires notification, or scenarios where you need to archive information before it's removed.

⚠️ WARNING: Delete triggers fire before the record is actually deleted, which means the record's data is still available for placeholders in your email. However, by the time the email sends and recipients read it, the record may no longer exist in Business Central. Make sure your email content explains that the record has been or will be deleted, and consider whether recipients need any of the record's data preserved in the email itself since they won't be able to access it later.

Before vs After Timing

For each type of event (insert, modify, delete), Business Central provides two timing options: "before" the operation commits to the database, and "after" the operation has been committed. The QUALIA Rule Engine, and by extension the Advanced Email App, uses only "before" timing because this timing provides several critical advantages:

Before Timing Advantages:

• All field values are available for use in placeholders and scenario conditions

• The transaction hasn't committed yet, so you can still prevent the operation if needed (though email notifications typically don't prevent operations—they just send notifications about them)

• Consistent timing across all trigger types

• Reliable execution before users see completion messages

The Advanced Email App doesn't expose timing as a configuration option because it always uses before timing. When you configure an insert, modify, or delete trigger, the system automatically uses the appropriate before timing (Before Insert, Before Modify, Before Delete) internally. You don't need to think about or configure timing—the system handles it correctly.

📋 NOTE: The use of before timing means email notifications send before Business Central commits the transaction. In rare cases where the transaction fails after the email sends (due to errors, validation failures, or system issues), recipients might receive an email about a transaction that didn't actually complete. This is generally not a significant concern for email notifications (unlike error messages or validations where timing is critical), but be aware of this possibility when troubleshooting situations where users report receiving emails about records that don't exist.

Choosing the Right Trigger

Selecting the appropriate trigger type for your email notification depends on what business event you want to respond to:

Use Insert Triggers When:

• You need to send notifications about new records being created

• You want to welcome new customers, confirm new orders, or acknowledge new registrations

• The notification purpose is "something new has been created"

• Example scenarios: order confirmations, new customer welcome emails, new vendor registration notifications

Use Modify Triggers When:

• You need to send notifications about changes to existing records

• You want to alert users when specific field values change (status, amounts, dates, etc.)

• The notification purpose is "something has changed" or "a threshold has been reached"

• Example scenarios: status change notifications, credit limit warnings, approval requests, shipment date changes

Use Delete Triggers When:

• You need to send notifications about records being removed

• You want to maintain audit trails of deletions

• You need approval or acknowledgment before important records are deleted

• Example scenarios: customer deletion notifications, order cancellation alerts, inventory adjustment records

Most Common Pattern: The vast majority of email notifications use modify triggers on status or state fields. Business processes typically involve records moving through workflow stages (Order created → Order released → Order shipped → Order invoiced), and notifications at each stage are implemented as modify triggers on status fields.

4.2 Configuring Trigger Settings

The Triggers section on the Email card page is where you specify what data changes will cause your email to send. Understanding each field in this section and how they work together ensures your emails trigger at exactly the right moment.

Selecting Source Tables

The Table field in the Triggers section specifies which Business Central table to monitor for changes. Every record in Business Central belongs to a specific table—sales orders are in the Sales Header table, customers are in the Customer table, items are in the Item table, and so forth. When you specify a table in your trigger configuration, you're telling the system "watch this table for changes."

To select a source table:

1. In the Triggers section of the Email card page, click in the Table field.

2. You can either:

   • Enter the table number directly if you know it (e.g., "36" for Sales Header)

   • Enter part of the table name and let Business Central's lookup help you find it (e.g., type "sales header" and select from the list)

   • Click the lookup button (three dots or down arrow) to browse available tables

3. Select the appropriate table for your notification scenario.

Common Business Central Tables:

💡 TIP: When deciding which table to use as your trigger table, consider where the most relevant data for your email resides. If you're sending order-level notifications (overall order status, order amount), use the Sales Header table. If you're sending line-level notifications (specific item quantities, line discounts), use the Sales Line table. If you need data from multiple tables, use the table that triggers the notification and configure source references (covered in Section 4.5) to access related data.

Selecting Trigger Fields

The Field field in the Triggers section specifies which field within the selected table to monitor for changes. This field-level specification is particularly important for modify triggers because it allows you to respond to specific field changes rather than any change to the record.

To select a trigger field:

1. After selecting a table, click in the Field field.

2. You can either:

   • Enter the field number directly if you know it (e.g., "120" for Status in Sales Header)

   • Enter part of the field name to search (e.g., type "status")

   • Use the lookup to browse available fields

3. Select the field whose changes should trigger your email.

Important Field Selection Considerations:

For Insert Triggers: The field selection is less critical because insert triggers fire when the entire record is created. However, Business Central requires a field to be specified. Common practice is to select a key field like the primary key or a status field.

For Modify Triggers: Field selection is critical. The email sends only when the specified field changes. Choose fields that represent meaningful state changes, not fields that change frequently for administrative reasons. For example:

• ✅ GOOD: Status field (changes indicate workflow progression)

• ✅ GOOD: Credit Limit field (changes may require approval)

• ❌ POOR: Last Date Modified field (changes every time anyone touches the record)

• ❌ POOR: Description field (changes don't typically require notification)

For Delete Triggers: Field selection is less critical because delete triggers fire when the record is being deleted. Select the primary key field or a status field.

Common Trigger Fields by Table:

Setting Trigger Timing

The Advanced Email App simplifies trigger timing by automatically using "before" timing for all triggers (as explained in Section 4.1). However, you do need to specify which event types (insert, modify, delete) should trigger your email by checking the appropriate columns in the Triggers section:

Insert Column: Check this box if you want the email to send when new records are created in the trigger table. When checked, the system creates a "Before Insert" trigger internally.

Modify Column: Check this box if you want the email to send when the specified trigger field is changed in existing records. When checked, the system creates a "Before Modify" trigger internally.

Delete Column: Check this box if you want the email to send when records are deleted from the trigger table. When checked, the system creates a "Before Delete" trigger internally.

You can check multiple boxes if you want the email to trigger on more than one event type. For example, checking both Insert and Modify means the email sends both when new records are created and when the specified field changes in existing records.

Common Trigger Patterns:

✅ EXAMPLE: Sales Order Status Change Notification

Business Scenario: Send an email to the sales manager whenever a sales order's status changes from Open to Released.

Trigger Configuration:

This configuration creates a modify trigger that fires when the Status field changes. To ensure the email sends only when changing from Open to Released (not for other status changes), you would add a scenario condition (covered in Section 4.3) that checks for Status = Released.

Multiple Triggers per Email

An email template can have multiple trigger configurations, allowing the same email to send in response to different events or from different tables. This capability is useful when the same notification is appropriate for several related scenarios.

To add multiple triggers:

1. Configure the first trigger as described above.

2. Click in the next empty row in the Triggers section.

3. Configure the second trigger with potentially different table, field, or event type settings.

4. Repeat for additional triggers as needed.

When you configure multiple triggers, the email can send from any of the configured triggers. If any trigger condition is met, the email sends. Think of multiple triggers as providing multiple pathways to send the same email.

✅ EXAMPLE: Multiple Document Type Notifications

Business Scenario: Send the same confirmation email when sales orders, quotes, or invoices are created.

Trigger Configuration:

This configuration ensures the email sends when any of the three document types is created. You could achieve a similar result with a single trigger and a more complex scenario, but multiple triggers can sometimes be clearer.

📋 NOTE: When using multiple triggers, be careful not to create overlapping trigger conditions that would cause the same email to send multiple times for a single event. For example, if you have both an insert trigger and a modify trigger on the same table/field, creating a new record might fire both triggers depending on how Business Central initializes the record, resulting in duplicate emails.

4.3 Understanding Scenarios (Filters)

Scenarios, also called filters or conditions in various contexts, provide fine-grained control over when emails actually send by allowing you to specify additional criteria beyond just the trigger event. While a trigger defines the broad category of changes that might warrant an email ("when sales order status changes"), scenarios define the specific circumstances when the email should actually send ("but only when status changes to Released, and only for orders over $10,000, and only for US customers").

What Are Scenarios?

A scenario in the QUALIA Rule Engine is a filtering condition that must be satisfied for the email to send. When your email's trigger fires, the Rule Engine doesn't immediately send the email—first, it evaluates any scenario conditions you've configured. Only if all scenario conditions are met (or if no scenarios are configured, meaning no additional filtering is required) does the email actually send.

Think of scenarios as answering the question "under what circumstances should this email send?" after the trigger has answered "when should we check if this email should send?" This two-stage evaluation (trigger determines when to check, scenarios determine whether to proceed) provides flexibility to create highly targeted email notifications that send only when truly appropriate.

Scenarios use the same filter syntax as Business Central's native filtering functionality, which means if you're familiar with setting filters in Business Central list pages or report request pages, you already understand the basic syntax for scenario conditions. The main difference is that scenario filters use placeholder syntax to reference field values rather than specifying static filter values.

When to Use Scenario Filters

Not every email notification requires scenario filters. Simple notifications that should send every time the trigger event occurs don't need scenarios. However, many real-world email notifications benefit from scenario filtering:

Use Scenarios When:

• You need to send emails only when specific conditions are met (status = a particular value, amount > a threshold, date within a range)

• You want to exclude certain situations from triggering emails (don't send for certain document types, certain customer types, certain locations)

• You need to combine multiple conditions (status = Released AND amount > 10000 AND customer country = 'US')

• You want to prevent emails from sending in test or development scenarios

Don't Use Scenarios When:

• Every occurrence of the trigger event should send an email

• The trigger event itself is specific enough that no additional filtering is needed

• You want maximum simplicity in your configuration

✅ EXAMPLE: When Scenarios Are Needed

Without Scenario (Too Broad):

With Scenario (Properly Targeted):

Trigger: Sales Header, Status field, Modify
Scenario: [36:120]

The scenario provides the specificity needed to send emails only in the intended situation.

4.4 Creating Scenario Conditions

Scenario conditions are configured in the Scenarios section of the Email card page. Understanding the syntax and how to write effective conditions is essential for creating targeted email notifications.

Field-Based Conditions

The most common type of scenario is a condition that checks a field value against a specific value or range. The syntax follows Business Central's native filter syntax with placeholders.

To create a field-based scenario:

1. In the Scenarios section of the Email card page, click in an empty row to add a new scenario.

2. In the Type field, select Scenario (as opposed to Condition, which is used internally for the email action itself).

3. In the FilterString field, enter your filtering condition using the syntax:

   [TableID:FieldID]

Basic Scenario Examples:

Check if field equals specific value:

[36:120]

This checks if Sales Header Status (field 120) equals 1 (Released).

Check if field does not equal value:

[36:120]

This checks if Status is not equal to 0 (not Open). Note the syntax: is <> followed by the value.

Check if field greater than value:

[36:61]

This checks if Amount (field 61) is greater than 10,000.

Check if field less than value:

[27:22]

This checks if Inventory (field 22) is less than 50.

Check if field in range:

[36:61]

This checks if Amount is between 1,000 and 5,000 (inclusive).

Check if field is one of multiple values:

[18:35]

This checks if Country Code (field 35) is US, Canada, or Mexico.

📋 NOTE: The keyword is is required in scenario filter syntax. Simply writing [36:120] 1 without is will not work. The correct syntax is always [TableID:FieldID] is value or [TableID:FieldID] is operator value.

Comparison Operators

QUALIA supports standard Business Central filter operators:

Value Type Considerations:

Text values: Enclose in single quotes:

[18:35]

Numeric values: No quotes needed:

[36:61]

Date values: Use Business Central date format for your region:

[36:19]

Boolean values: Use true/false or 1/0:

[18:1]

Value Comparisons

Scenarios can compare field values to static values (as shown above) or to other field values using placeholders on both sides of the comparison.

Comparing current value to old value (modify triggers only):

On modify triggers, you can compare the new field value to the previous value using curly braces {} for the old value:

[37:15]

This checks if the new Quantity value is greater than the old Quantity value, effectively detecting quantity increases.

Comparing two different fields:

[36:61] is >[18:39]

This compares the order Amount (36:61) to the customer's Credit Limit (18:39), checking if the order exceeds the customer's credit limit.

⚠️ WARNING: Comparing values between different tables requires proper configuration of source references (covered in Section 4.5). If you try to compare fields from tables that aren't linked through source references, the comparison may not work correctly or the Rule Engine may not be able to access the data.

Multiple Condition Logic

Business Central's filter syntax does not support explicit AND/OR operators in a single filter string. Instead, multiple conditions are combined through multiple scenario rows, and the Rule Engine interprets these according to specific logic:

Multiple Scenarios = AND Logic

When you add multiple scenario rows to an email configuration, ALL scenarios must match for the email to send. This is implicit AND logic—each scenario adds another requirement that must be satisfied.

✅ EXAMPLE: High-Value US Customer Orders

Business Scenario: Send email only when all these conditions are true:

• Order status is Released

• Order amount exceeds $10,000

• Customer is in the United States

Scenario Configuration:

Scenario 1: [36:120] is 1
Scenario 2: [36:61] is >10000
Scenario 3: [18:35]

All three scenarios must match for the email to send. If status is Released and amount exceeds $10,000 but customer is in Canada, the email won't send because the third scenario doesn't match.

Single Scenario with Multiple Values = OR Logic

When you use the multiple values operator (|) within a single scenario, any matching value satisfies that scenario:

[18:35]

This creates OR logic for those specific values—customer can be in US OR Canada OR Mexico for the scenario to match.

📋 NOTE: Complex OR logic across different fields cannot be expressed in a single email template's scenarios. If you need "send email when condition A is true OR when condition B is true" where A and B involve different fields or complex logic, you typically need to create separate email templates, each with its own trigger and scenario configuration for one of the conditions.

4.5 Working with Linked Tables

Many email notifications need to include data from multiple related tables. For example, when sending an order confirmation triggered by a Sales Header record, you might want to include data not just from the Sales Header table but also from the related Customer table, the Salesperson table, the Ship-to Address information, and other related data. Linked tables, also called source references in the QUALIA Rule Engine, provide the mechanism for accessing data from tables other than the trigger table.

Cross-Table References

When you use placeholders like [18:2] in your email to reference customer name, the Rule Engine needs to know how to get from your trigger record (a sales order in the Sales Header table) to the related customer record. Business Central tables have defined relationships—Sales Header has a Sell-to Customer No. field that links to the Customer table's No. field. Source references configure these relationships so the Rule Engine can traverse them to access related data.

Without source references, you can only use placeholders from your trigger table. With source references properly configured, your placeholders can access data from any table that has a defined relationship path to your trigger table, either directly or through intermediate tables.

Source Reference Configuration

Source references are configured in the Reference or Source References section of the email configuration interface (the exact name varies by interface version, but it's typically near the Scenarios section).

To configure a source reference:

1. In the Source References section, click in an empty row to add a new reference.

2. In the Reference Table field, enter the table number of the related table you want to access. For example, if your trigger is Sales Header and you want to access Customer data, enter "18" (Customer table).

3. In the Source Table field, this should typically match your trigger table, though in complex scenarios it might differ.

4. Configure the linking fields that define the relationship between the tables. This typically involves specifying which field in your trigger table contains the value that matches a field in the reference table.

Common Source Reference Patterns:

Sales Header → Customer:

This reference allows you to use customer placeholders like [18:2] (Customer Name), [18:102] (Customer Email), etc., in emails triggered by Sales Header changes.

Sales Header → Salesperson/Purchaser:

This reference allows you to use salesperson data like [13:5052] (Salesperson Email) in sales order emails.

Purchase Header → Vendor:

This reference allows you to use vendor data in purchase order emails.

💡 TIP: The default templates created by the "Create Default Data" action include properly configured source references for common scenarios. Examining these templates shows you how source references are structured for typical use cases, which you can then replicate for your own custom emails.

Using Data from Related Tables

Once source references are configured, using data from related tables in your emails is straightforward—simply use placeholders with the related table's ID and field IDs:

Email Template Example with Related Table Data:

Subject: Order [36:3] for Customer [18:2]

Body:
Hello [18:2],

Thank you for your order [36:3].

Order Details:
- Order Date: [36:19]
- Total Amount: [36:61]

Customer Information:
- Account No.: [18:1]
- Credit Limit: [18:39]
- Contact: [18:5]
- Phone: [18:9]
- Email: [18:102]

Your salesperson: [13:3]
Salesperson Email: [13:5052]

In this example:

• [36:...] placeholders reference the Sales Header trigger table

• [18:...] placeholders reference the Customer table (via source reference)

• [13:...] placeholders reference the Salesperson table (via source reference)

All placeholders work seamlessly because the source references define how to navigate from Sales Header to these related tables.

⚠️ WARNING: If you use placeholders from tables that don't have configured source references, the placeholders will appear literally in the sent email (as "[18:2]" for example) rather than being replaced with data. If you see literal placeholder text in your emails, verify that source references are configured for all tables you're referencing.

Common Linked Table Examples

Sales Order Emails: Typical source references for sales order notifications:

• Customer (18) - For customer details, email, addresses

• Salesperson (13) - For salesperson information

• Ship-to Address (222) - For shipment details

• Payment Terms (3) - For payment information

• Location (14) - For shipping location details

Purchase Order Emails: Typical source references for purchase order notifications:

• Vendor (23) - For vendor details, email, addresses

• Purchaser (13) - For buyer information

• Location (14) - For receiving location details

• Payment Terms (3) - For payment information

Inventory Alerts: Typical source references for inventory notifications:

• Item (27) - For item details

• Item Category (5722) - For categorization

• Location (14) - For location-specific inventory

• Vendor (23) - For reorder supplier information

4.6 Email Actions and Conditions

Every email notification in the Advanced Email App requires a "Condition" type formula that tells the Rule Engine to actually send the email. This might seem redundant since you've already configured triggers and scenarios, but it's a structural requirement of how the Rule Engine works. The Advanced Email App typically creates this condition automatically, but understanding what it does helps troubleshoot situations where emails don't send as expected.

Understanding the Condition Formula

In Rule Engine terminology, a "Condition" (as opposed to a "Scenario") is a formula that executes an action. For email notifications, you need a Condition formula with Action Type "Send Email" that references your email template code. This Condition is what actually triggers the email send operation after the trigger fires and scenarios pass.

The structure conceptually looks like:

📋 NOTE: The Advanced Email App's interface abstracts most of this complexity from you. When you configure an email in the simplified Advanced Email interface and save it, the system creates the necessary Condition and Action configurations automatically. You typically don't need to manually configure these unless you're working directly in the full Rule Engine interface.

Action Type: Send Email

The Send Email action type (one of the 11 action types in the QUALIA Rule Engine) specifically sends an email using a configured email template. When this action executes:

1. The Rule Engine loads the email template identified by the Action Code

2. Processes all placeholders in recipients, subject, and body, replacing them with actual data values

3. Generates any report attachments, applying filters automatically

4. Attaches any fixed file attachments

5. Sends the email through Business Central's email infrastructure

6. Logs the execution in the Validation Log

Linking Actions to Email Templates

The critical link between the action and your email content is the Action Code field, which must contain the Code value of your email template. This tells the Rule Engine which email template to use when the action executes.

For example:

• Your email template has Code = "ORD-CONFIRM"

• The action configuration must have Action Code = "ORD-CONFIRM"

• When the action executes, it loads the ORD-CONFIRM template and sends that email

If the Action Code doesn't match any existing email template code, the action fails and no email sends. The Validation Log will contain an error message indicating that the specified email template was not found.

💡 TIP: If you modify an email template's Code after it's been configured, you must also update the Action Code in any actions that reference it. Otherwise, the actions will continue looking for the old code and fail to find the template.

Testing Action Execution

To verify that your email action configuration is working correctly:

1. Create or identify a test record that will trigger your email

2. Perform the action that fires the trigger (create a record, modify a field, etc.)

3. Check the Validation Log (search for "Validation Log" in Business Central)

4. Look for a log entry related to your email

5. Verify:

   • The action executed (log entry exists)

   • No errors occurred (no error messages in log)

   • The correct email template was used (Action Code matches your template)

6. Check your email inbox to confirm the email was actually sent and received

If the Validation Log shows no entry, the trigger or scenarios may be preventing execution. If the log shows errors, the error messages typically indicate what went wrong (template not found, placeholder errors, email system problems, etc.).

4.7 Practical Trigger Examples

This section provides complete, real-world examples of email trigger configurations for common business scenarios. Use these examples as templates for creating your own email notifications, adjusting table and field IDs, placeholder references, and content to match your specific requirements.

Order Confirmation Emails

Business Scenario: When a sales order is created, automatically send a confirmation email to the customer with order details and a PDF attachment of the order confirmation report.

Configuration:

Email Content:

Code: ORD-CONFIRM
Description: Sales Order Confirmation to Customer

To: [18:102]
Cc: [13:5052]
Subject: Order Confirmation - Order [36:3]

Body:
<p>Dear [18:2],</p>

<p>Thank you for your order. We have received your order and it is being processed.</p>

<p><strong>Order Summary:</strong></p>
<ul>
  <li><strong>Order Number:</strong> [36:3]</li>
  <li><strong>Order Date:</strong> [36:19]</li>
  <li><strong>Total Amount:</strong> [36:179]</li>
  <li><strong>Expected Ship Date:</strong> [36:44]</li>
</ul>

<p>Your order will be processed within 2-3 business days.</p>

<p>If you have questions, please contact your salesperson [13:3] at [13:5052].</p>

<p>Thank you for your business!</p>

Attachments:

Type: Report
Report ID: 1305 (Standard Sales Order)
File Name: Order_[36:3]

Triggers:

Scenarios:

Scenario 1: [36:1]

Source References:

Result: When a new sales order is created (not quotes or invoices), the system sends a confirmation email to the customer's email address with a copy to the salesperson, including an order confirmation PDF attachment.

Credit Limit Warnings

Business Scenario: When a sales order's amount exceeds the customer's credit limit, send a warning email to the sales manager for review and approval.

Configuration:

Email Content:

Code: CREDIT-WARN
Description: Credit Limit Exceeded Warning

To: salesmanager@company.com
Cc: [13:5052]
Subject: CREDIT ALERT: Order [36:3] - Customer [18:2]

Body:
<p><strong style="color: red;">CREDIT LIMIT EXCEEDED</strong></p>

<p>A sales order has been created that exceeds the customer's credit limit.</p>

<p><strong>Order Information:</strong></p>
<ul>
  <li><strong>Order Number:</strong> [36:3]</li>
  <li><strong>Order Amount:</strong> [36:179]</li>
  <li><strong>Order Date:</strong> [36:19]</li>
</ul>

<p><strong>Customer Information:</strong></p>
<ul>
  <li><strong>Customer:</strong> [18:2]</li>
  <li><strong>Customer No.:</strong> [18:1]</li>
  <li><strong>Credit Limit:</strong> [18:39]</li>
  <li><strong>Current Balance:</strong> [18:59]</li>
</ul>

<p><strong>Salesperson:</strong> [13:3]</p>

<p style="background-color: yellow; padding: 10px;">
<strong>Action Required:</strong> Please review this order and determine if an exception should be granted or if the order should be held pending payment.
</p>

Triggers:

Scenarios:

Scenario 1: [36:179] is >[18:39]
(Order Amount exceeds Customer Credit Limit)

Scenario 2: [36:1]

Source References:

Result: When an order is created or modified such that its amount exceeds the customer's credit limit, an alert email sends to the sales manager with full details for review.

Shipment Notifications

Business Scenario: When a sales shipment is posted, automatically notify the customer that their order has shipped.

Configuration:

Email Content:

Code: SHIP-NOTIFY
Description: Shipment Notification to Customer

To: [18:102]
Subject: Your Order [110:12] Has Shipped

Body:
<p>Dear [18:2],</p>

<p>Good news! Your order has been shipped and is on its way to you.</p>

<p><strong>Shipment Details:</strong></p>
<ul>
  <li><strong>Shipment No.:</strong> [110:3]</li>
  <li><strong>Order No.:</strong> [110:12]</li>
  <li><strong>Shipment Date:</strong> [110:11]</li>
  <li><strong>Ship-to Address:</strong> [110:13], [110:14], [110:15]</li>
</ul>

<p>You should receive your shipment within 5-7 business days.</p>

<p>Thank you for your business!</p>

Attachments:

Type: Report
Report ID: 208 (Sales Shipment)
File Name: Shipment_[110:3]

Triggers:

Scenarios:

Source References:

Result: When a sales shipment is posted, the system automatically sends a notification email to the customer with shipment details and a PDF of the shipment document.

Payment Reminders

Business Scenario: When customer invoices are approaching their due date (7 days before due), send a friendly payment reminder.

Configuration:

Email Content:

Code: PAY-REMIND
Description: Payment Reminder - Due Date Approaching

To: [18:102]
Subject: Payment Reminder - Invoice [112:3]

Body:
<p>Dear [18:2],</p>

<p>This is a friendly reminder that payment for the following invoice is due soon:</p>

<p><strong>Invoice Details:</strong></p>
<ul>
  <li><strong>Invoice No.:</strong> [112:3]</li>
  <li><strong>Invoice Date:</strong> [112:11]</li>
  <li><strong>Due Date:</strong> [112:13]</li>
  <li><strong>Amount Due:</strong> [112:109]</li>
</ul>

<p>Please ensure payment is sent before the due date to avoid late fees.</p>

<p>If you have already sent payment, please disregard this reminder.</p>

<p>Thank you for your business!</p>

Triggers:

Scenarios:

Scenario 1: [112:13] is [TODAY]

Source References:

📋 NOTE: This example demonstrates a date range scenario. The actual implementation of "7 days from today" may require date calculation functionality that varies by Business Central version. Consult your Business Central consultant for the appropriate date comparison syntax for your version.

Approval Notifications

Business Scenario: When a sales order is released (status changes to Released), send a notification to the order processor to begin fulfillment.

Configuration:

Email Content:

Code: ORD-RELEASED
Description: Order Released - Ready for Processing

To: orderfulfillment@company.com
Subject: Order [36:3] Released - Ready to Process

Body:
<p>Hello Order Processing Team,</p>

<p>The following sales order has been released and is ready for fulfillment:</p>

<p><strong>Order Details:</strong></p>
<ul>
  <li><strong>Order No.:</strong> [36:3]</li>
  <li><strong>Customer:</strong> [18:2]</li>
  <li><strong>Order Date:</strong> [36:19]</li>
  <li><strong>Requested Ship Date:</strong> [36:44]</li>
  <li><strong>Total Amount:</strong> [36:179]</li>
</ul>

<p><strong>Priority:</strong> 
[IF [36:179] > 10000 THEN "HIGH PRIORITY" ELSE "Normal"]
</p>

<p>Please begin processing this order according to standard procedures.</p>

Triggers:

Scenarios:

Scenario 1: [36:120] is 1
(Status = Released)

Scenario 2: [36:1]

Source References:

Result: When a sales order's status is changed to Released, the order fulfillment team receives a notification that the order is ready to process, with priority flagging for high-value orders.

Status Change Alerts

Business Scenario: Monitor all status changes on purchase orders and notify the purchasing manager of workflow progression.

Configuration:

Email Content:

Code: PO-STATUS
Description: Purchase Order Status Change Notification

To: purchasingmanager@company.com
Subject: PO [38:3] Status Changed - Now [38:120]

Body:
<p>Hello Purchasing Manager,</p>

<p>A purchase order status has changed:</p>

<p><strong>Purchase Order Information:</strong></p>
<ul>
  <li><strong>PO Number:</strong> [38:3]</li>
  <li><strong>Vendor:</strong> [23:2]</li>
  <li><strong>New Status:</strong> [38:120]</li>
  <li><strong>Order Date:</strong> [38:19]</li>
  <li><strong>Total Amount:</strong> [38:94]</li>
</ul>

<p><strong>Purchasing Agent:</strong> [13:3]</p>

<p>No action required - this is for your information.</p>

Triggers:

Scenarios:

Scenario 1: [38:1]

Source References:

Result: Whenever a purchase order's status changes, the purchasing manager receives an informational notification tracking the order's workflow progression.