Chapter 2: Creating and Managing Notifications

This chapter explores the complete lifecycle of notification configuration, from initial creation through ongoing management and maintenance. You'll learn how to compose effective notification messages, leverage placeholders for dynamic content, work with notification data fields, and manage notification scopes. By the end of this chapter, you'll understand how to create sophisticated, context-aware notifications that provide exactly the right information at the right time to your users.

The chapter progresses from basic concepts to advanced techniques, building on the foundation established in Chapter 1. Each section includes practical examples drawn from real business scenarios, ensuring you can immediately apply what you learn to your own notification requirements.

2.1 Notification Basics

Planning Your Notification Strategy

Before creating individual notifications, it's worth considering your overall notification strategy. Effective notification systems share common characteristics that prevent notification fatigue while ensuring important information reaches users:

Notification Purpose and Value:

Every notification should have a clear purpose that serves the business:

• Information: Confirm that an action completed successfully

• Alert: Notify users of conditions requiring awareness

• Action Request: Inform users that they need to take specific action

• Status Change: Communicate that a record's state has changed

📋 NOTE: Avoid creating notifications for events users don't need to know about. Too many notifications reduce attention to important alerts. Ask: "Does this event require immediate user awareness, or can it wait for scheduled reports?"

Audience Considerations:

Different user roles have different information needs:

• Data Entry Users: Need confirmation of successful saves, validation errors, and duplicate warnings

• Managers: Need alerts about approvals, exceptions, and threshold breaches

• Executives: Need high-level status changes and critical alerts only

Use Rule Groups (covered in Chapter 5) to ensure notifications reach appropriate audiences without overwhelming users with irrelevant information.

Timing and Urgency:

Consider when users need to know about events:

• Immediate: Use GlobalScope for urgent situations requiring action

• Current Task: Use LocalScope for context-specific information

• Batch Processing: Consider whether notifications should trigger during batch operations

Message Design Principles:

Effective notification messages are:

• Concise: Under 100 characters when possible

• Specific: Include identifying information (document numbers, names)

• Actionable: Clear about what (if anything) the user should do

• Professional: Maintain consistent tone and terminology

💡 TIP: Write notification messages in plain language as if speaking to a colleague. Avoid technical jargon, table names, or field names that business users won't understand. "Sales Order SO-001 requires approval" is better than "Table 36 Record SO-001 Status = 3".

Creating a New Notification

The process of creating a notification follows a consistent pattern, regardless of complexity:

Access the Notification Configuration Page

1. Press Alt+Q to open the search box

2. Type "Advanced Notifications"

3. Select Advanced Notifications from the results

4. The list page displays all existing notifications

Create a New Record

1. Click New in the ribbon or press Ctrl+N

2. The system opens a blank notification card

3. The Code field is populated based on your number series configuration

   • If you want a specific code, click the assist-edit button (…) to see available numbers

   • Or enter a code manually if your number series allows it

Configure Basic Information

Code Field:

• Automatically assigned from number series (e.g., "NOTIF-00001")

• Must be unique across all notifications

• Cannot be changed after saving if used in validation logs

• Use meaningful prefixes for organization (e.g., "SALES-", "PURCH-", "APPR-")

Description Field:

• Human-readable explanation of what the notification does

• Displayed in lists and logs

• Should be descriptive enough that other administrators understand the purpose

• Maximum 100 characters

• Examples:

  • "Sales Order Released Notification"

  • "Purchase Invoice Approval Required"

  • "Customer Credit Limit Exceeded Alert"

Notification Text Field:

• The actual message users will see

• Supports placeholders for dynamic content

• Maximum 250 characters (practical limit for readability)

• Can include field values, calculations, and formatting

Global Scope Checkbox:

• Checked = GlobalScope (notification persists across pages)

• Unchecked = LocalScope (notification disappears when leaving page)

• Default is unchecked (LocalScope)

✅ EXAMPLE - Well-Designed Notification:

Code: SALES-RELEASE-001
Description: Notify sales team when orders are released
Notification Text: Order [36:3] released for [36:79] - Amt: [36:110]

This notification:

• Has a meaningful code with a prefix

• Clearly describes its purpose

• Includes three key data points (order number, customer, amount)

• Uses LocalScope since it's informational, not action-required

Naming Conventions and Organization

Establishing consistent naming conventions makes notifications easier to manage, especially in large implementations with dozens of notification configurations:

Code Prefixes:

Organize notifications by business area or function:

• SALES-: Sales-related notifications

• PURCH-: Purchasing notifications

• INV-: Inventory notifications

• APPR-: Approval notifications

• FIN-: Financial notifications

• ALERT-: Critical alerts

• INFO-: Informational messages

Description Patterns:

Use consistent description formats:

• Start with the trigger event: "When Sales Order is Released..."

• Or start with the action: "Notify users when..."

• Include the subject: "...for purchase invoices over $10,000"

• Keep it concise but complete

Configuration Grouping:

Group related notifications logically:

• All order-related notifications together

• All approval notifications together

• All alerts by severity level

This organization helps when:

• Searching for specific notifications to modify

• Troubleshooting notification issues

• Training new administrators

• Documenting your notification system

💡 TIP: Create a naming convention document and share it with all administrators. Consistent naming prevents confusion and makes it easier to hand off maintenance responsibilities. Include the document in your internal wiki or documentation repository.

Saving and Activating Notifications

Unlike some business rule systems, notifications in the Advanced Notification App become active immediately upon saving. There's no separate activation, deployment, or publishing step.

Save Behavior:

When you click OK or press Ctrl+S:

1. Business Central validates the notification configuration

2. The system saves the record to the database

3. The Rule Engine immediately includes this notification in its evaluation cycle

4. Any triggers you configured start monitoring their source tables

Validation Rules:

The system validates several conditions before allowing save:

• Code must be unique

• Description cannot be empty

• Notification Text cannot be empty

• Trigger table numbers must exist in the database

• Scenario formulas must use valid syntax (Chapter 4 covers syntax rules)

If validation fails, an error message explains the issue and prevents saving until corrected.

📋 NOTE: Because notifications activate immediately, always test new configurations in a sandbox or test environment first. A misconfigured trigger could fire unexpectedly or generate excessive notifications, disrupting user workflows.

Modifying Existing Notifications:

You can modify notifications at any time:

1. Open the notification from the list page

2. Make your changes

3. Save the record

Changes take effect immediately. Any in-flight evaluations use the old configuration, but new trigger events use the updated configuration.

Deactivating Notifications:

There's no explicit "deactivate" function. To temporarily disable a notification:

Option 1: Delete triggers - Remove all trigger configurations. Without triggers, the notification never evaluates.

Option 2: Set impossible scenario - Add a scenario with condition [1:1] = 'DISABLED'. This condition always evaluates to false, preventing notification display.

Option 3: Delete the notification - Permanently remove the configuration. Use cautiously as this cannot be undone.

Option 4: Disable globally - In Advanced Notification Setup, uncheck "Enable Business Rule" to disable ALL notifications system-wide.

⚠️ WARNING: Deleting a notification removes all associated configuration including triggers, scenarios, actions, and data fields. The configuration cannot be recovered unless you've exported templates. Before deleting, consider exporting the notification to XML for backup purposes (covered in Chapter 6).

2.2 Composing Notification Messages

Writing Effective Message Text

The notification message is what users see, making it the most important aspect of your configuration. Effective messages are clear, concise, and provide actionable information without requiring users to investigate further.

Message Content Guidelines:

1. Lead with the Key Information:

• Put the most important data first

• "Order SO-001 requires approval" is better than "Approval is required for order SO-001"

• Users should understand the situation in the first few words

2. Include Identifying Details:

• Always include unique identifiers (document numbers, customer names, IDs)

• "Invoice 12345 posted" is better than "Invoice posted"

• Users need to know WHICH record the notification refers to

3. State the Status or Action:

• Make clear what happened or what's needed

• "Payment received" vs. "Payment pending"

• "Approval required" vs. "Approved" vs. "Rejected"

4. Keep It Short:

• Target 50-80 characters for ideal readability

• Maximum 250 characters (technical limit)

• Every word should add value

5. Use Consistent Terminology:

• Match the language used in Business Central pages

• Use terms familiar to your users

• Maintain consistent tone across all notifications

✅ EXAMPLE - Message Comparison:

Poor: A record in the system has been changed and requires your attention for approval purposes

• Too vague (which record?)

• Too wordy (24 words)

• No identifying information

• Unclear what action is needed

Good: Order SO-1001 awaits approval - $25,400

• Specific (Order SO-1001)

• Concise (7 words)

• Includes key data (amount)

• Clear action (approval)

Handling Different Notification Types:

Confirmation Messages:

• Include checkmark or confirmation language

• Reference the specific record

• Keep very brief

Alert Messages:

• Use warning indicators when appropriate

• State the problem condition

• Include relevant thresholds or quantities

Action Required Messages:

• Use action indicators

• State what's needed

• Make the required action obvious

Status Change Messages:

• Show state transitions clearly

• Include before/after when relevant

• Reference related documents

💡 TIP: Test your message text with actual users before widespread deployment. What seems clear to an administrator might confuse end users. Ask users to read the message and explain what it means—if they struggle, revise the wording.

Character Limits and Formatting

Understanding Business Central's notification display constraints helps you design messages that display correctly across all clients:

Technical Limits:

• Database field: 250 characters maximum (enforced by the field definition)

• Practical display: 80-100 characters for optimal readability

• Multi-line: Not supported—notifications display as single lines

• HTML: Not supported—messages are plain text only

Character Count Considerations:

When counting characters, remember that placeholders expand to their actual values:

• [36:3] might expand to "SO-000001" (10 characters)

• [36:79] might expand to "Alpine Ski House Equipment Co." (32 characters)

• Plan for maximum expected field lengths, not placeholder length

✅ EXAMPLE - Character Planning:

Template: Order [36:3] for [36:79] - Amount: [36:110]

• Placeholder characters: 42

• Static text: 18 characters ("Order ", " for ", " - Amount: ")

• Total template: 60 characters

Actual display with data:

• [36:3] = "SO-000123" (9 characters)

• [36:79] = "Adatum Corporation" (18 characters)

• [36:110] = "45,250.00" (9 characters)

• Total displayed: 54 characters

Always test with realistic data values, especially fields that might contain long names or descriptions.

Formatting Techniques:

Since HTML and formatting aren't supported, use these plain-text techniques:

Separators:

• Dash: Order SO-001 - Released

• Colon: Customer: Alpine Ski House

• Arrow: Status: Open → Released

• Pipe: INV-001 | $5,000 | Overdue

Symbols:

• Checkmark: ✓ or ✔

• Warning: ⚠ or !

• Arrow: → or >>

• Bullet: • or -

Abbreviations:

• Amt: Amount

• Qty: Quantity

• Doc: Document

• Appr: Approval

• Inv: Invoice

📋 NOTE: Test symbols across all clients (Web, Windows, Mobile). Some symbols might not display correctly on all platforms. Stick to common Unicode symbols that have broad support.

Line Length and Wrapping:

Different Business Central clients handle long notifications differently:

• Web Client: Truncates after ~100 characters with "..."

• Windows Client: May wrap to two lines (but wrapping is unpredictable)

• Mobile: Truncates more aggressively due to smaller screens

Best Practice: Keep messages under 80 characters to ensure full display across all clients.

If you need to convey more information, use:

• Data fields (covered in section 2.5): Add structured key-value pairs

• Action buttons (covered in Chapter 3): Let users drill down for details

• Multiple notifications: Split complex updates into separate focused messages

2.3 Working with Placeholders

Placeholder Syntax and Structure

Placeholders are the mechanism for including dynamic data from Business Central tables in your notification messages. Understanding placeholder syntax is essential for creating informative, context-aware notifications.

Basic Placeholder Format:

[TableNumber:FieldNumber]

• Table Number: The numeric ID of the table containing the data

• Field Number: The numeric ID of the field within that table

• Square Brackets: Required delimiters

• Colon: Required separator

✅ EXAMPLE - Common Placeholders:

[36:3]    = Sales Header, No. field (Document Number)
[36:79]   = Sales Header, Sell-to Customer Name
[36:110]  = Sales Header, Amount Including VAT
[18:2]    = Customer, Name
[18:59]   = Customer, Balance (LCY)
[27:3]    = Item, No.
[27:4]

Finding Table and Field Numbers:

Several methods exist for discovering the correct table and field numbers:

Method 1: Use the FactBox

1. Open your notification card

2. Look at the Lookup Placeholder FactBox on the right side

3. Select a table from the dropdown

4. Browse fields to find the one you need

5. Click on a field to see its placeholder format

Method 2: Use Table Information Page

1. Search for "Table Information" in Business Central

2. Find the table you need

3. Note the Table No. field

4. Search for "Field" page for that table to see field numbers

Method 3: AL Object Browser (if available)

1. Open AL Object Browser extension in VS Code

2. Search for the table name

3. View all fields with their numbers

Method 4: Refer to Documentation

• Use Microsoft Docs for standard table reference

• Check your organization's customization documentation for custom tables

📋 NOTE: Custom table and field numbers vary by installation. Tables 50000-99999 are typically custom. Always verify custom object numbers in your specific environment before using in placeholders.

Using Placeholders in Notification Text

Placeholders can appear anywhere in your notification text. They're replaced with actual field values when the notification displays.

Single Placeholder Usage:

Notification Text: Order [36:3]

When triggered by Sales Order SO-001:

Multiple Placeholders:

Notification Text: [36:3] for customer [36:79] - Amount: [36:110]

When triggered:

You can mix placeholders with literal text naturally, and they'll resolve to create readable messages.

This completes Chapter 2, covering notification creation, message composition, placeholders, data fields, scopes, and configuration management.