Chapter 6: Template Management and Troubleshooting

6.1 Template Import and Export

Exporting Notification Templates

Exporting notifications creates XML files containing complete configuration:

Why Export:

• Backup: Save configurations before making changes

• Version control: Track configuration history

• Migration: Move notifications between environments (sandbox to production)

• Documentation: Create template library for reuse

• Disaster recovery: Restore after accidental deletion

Export Procedure:

1. Open Advanced Notifications list page

2. Select the notifications to export (or leave none selected to export all)

3. Click Actions → Export

4. The system generates an XML file containing selected notification configurations

5. Save the XML file to a secure location

XML File Contents:

The export includes:

• Notification Code, Description, Text, Scope

• All Data fields

• All Action button configurations

• All Trigger configurations

• All Scenario formulas

• Rule Group assignments

📋 NOTE: Exported XML does NOT include action codeunit code itself—only codeunit IDs and procedure names. Action codeunits must be deployed separately as AL extensions.

Importing Notification Templates

Importing loads notification configurations from XML files:

Import Procedure:

1. Open Advanced Notifications list page

2. Click Actions → Import

3. Select the XML file to import

4. Review the import preview (shows which notifications will be created/updated)

5. Confirm the import

Import Behavior:

New Notifications (Code doesn't exist):

• Creates new notification with all configurations

• Assigns new number series code if configured

Existing Notifications (Code already exists):

• Replace Mode: Overwrites existing notification completely

• Merge Mode: Updates existing notification, preserves local changes (if supported)

Validation During Import:

System validates:

• XML file structure is correct

• Table numbers exist in target environment

• Codeunit IDs exist (for action buttons)

• Rule Group codes exist

If validation fails, import stops and shows error message.

⚠️ WARNING: Importing replaces existing notifications with the same code. Always export current configuration before importing to preserve backup. Consider using test codes (e.g., "TEST-001") when importing experimental configurations.

Create Default Data Function

The Create Default Data function imports pre-configured example notifications:

Purpose:

• Quick start for new installations

• Example configurations to learn from

• Template library for common scenarios

Procedure:

1. Open Advanced Notifications list page

2. Click Create Default Data in the ribbon

3. System imports embedded XML resource

4. Example notifications appear in the list

What Gets Created:

Typically includes example notifications for:

• Sales order status changes

• Purchase order approvals

• Inventory alerts

• Customer credit warnings

⚠️ WARNING: Create Default Data REPLACES any existing notifications with the same codes. If you've customized default notifications, they'll be overwritten. Export before running Create Default Data.

💡 TIP: After running Create Default Data, review the example notifications and modify them for your needs. They're designed as starting points, not production-ready configurations.

6.2 Troubleshooting Notifications

Notification Never Triggers

Symptoms:

• Configure notification with trigger and scenario

• Test by modifying records

• Notification never appears

Diagnostic Steps:

1. Verify Enable Business Rule:

• Open Advanced Notification Setup

• Ensure Enable Business Rule is checked

• If unchecked, ALL notifications are disabled system-wide

2. Check Trigger Configuration:

• Verify Source Table No. is correct

• Verify appropriate event type is checked (Insert/Modify/Delete)

• If using Trigger String, verify field numbers are correct

• Test without Trigger String to see if it helps

3. Check Scenario Formulas:

• Scenario formulas might be preventing notification

• Temporarily remove all scenarios

• If notification appears, scenarios are blocking

• Review scenario logic and test formulas

4. Check Rule Group Assignments:

• Verify notification is assigned to a Rule Group

• Verify your user is in that Rule Group

• Test with notification assigned to "blank" group (all users)

5. Review Validation Log:

• Search for QUA Validation Log

• Filter by notification code

• Look for evaluation attempts

• Check failure reasons

📋 NOTE: The Validation Log is your best troubleshooting tool. It shows every trigger evaluation, scenario results, and why notifications did or didn't display.

Notification Triggers Too Frequently

Symptoms:

• Notification appears multiple times for single action

• Notification appears for unintended changes

• Users complain about notification spam

Solutions:

1. Add Trigger String: If monitoring Modify event without Trigger String, notification fires on ANY field change. Add specific field numbers to Trigger String.

2. Add More Restrictive Scenarios: If notification displays for unwanted conditions, add scenarios to filter:

[36:110] > 10000   // Only amounts above threshold
[36:5]

3. Check for Multiple Triggers: Review if notification has overlapping triggers that fire for same event.

4. Review Trigger Events: Ensure you're not monitoring both Insert AND Modify when you only need one.

Wrong Data Displays in Notification

Symptoms:

• Notification appears but shows incorrect values

• Blank fields where values expected

• Wrong record data

Solutions:

1. Verify Placeholder Syntax:

• Check table and field numbers: [36:3]

• Verify square brackets and colon

• No spaces inside brackets

2. Verify Field Numbers:

• Use FactBox to confirm correct field numbers

• Custom fields vary by environment

• Check table definition

3. Check Related Table Placeholders: If using fields from related tables, verify table relationship exists in BC.

4. Test with Simple Placeholders: Replace complex placeholders with simple ones to isolate issue.

Users Not Receiving Notifications

Symptoms:

• Some users see notifications, others don't

• Notification works for admin, not for regular users

Solutions:

1. Verify Rule Group Membership:

• Check user is in appropriate Rule Group

• Review QUA Rule Groups configuration

• Add user to required group

2. Check Permissions:

• User needs read permission on notification tables

• User needs execute permission on action codeunits

• Assign QUA Notification - View permission set

3. Verify User Active:

• Check user account is active in BC

• Verify user can log in

• Confirm no license restrictions

Action Buttons Don't Work

Symptoms:

• Notification appears correctly

• Click action button → error or nothing happens

Solutions:

1. Verify Codeunit ID:

• Check codeunit exists in environment

• Verify exact ID number matches configuration

• Test with simple codeunit first

2. Verify Procedure Name:

• Check spelling (case-sensitive)

• Ensure procedure accepts Notification parameter

• No typos in procedure name

3. Check Data Fields:

• Action code calls GetData() with field captions

• Verify Data Caption spelling matches exactly

• Add missing data fields to notification

4. Test Action Code Separately:

• Call action procedure manually from another codeunit

• Add error handling and logging to action code

• Check for runtime errors in action logic

💡 TIP: Add detailed error logging to action procedures during development:

if not SalesHeader.Get(OrderNo) then begin
    Message('DEBUG: Order %1 not found', OrderNo);
    exit;
end;

This helps identify exactly where action code fails.

6.3 Performance Optimization

Reducing Trigger Overhead

Issue: Too many notifications impacting system performance

Optimization Strategies:

1. Use Specific Trigger Strings: Don't monitor all field changes—specify exact fields that matter.

2. Consolidate Overlapping Notifications: Instead of 5 similar notifications with slightly different messages, create 1 notification with dynamic placeholders.

3. Disable Unused Notifications: Delete or disable notifications no longer needed.

4. Avoid FlowField-Heavy Scenarios: FlowFields calculating complex sums can be slow. Consider pre-calculated fields or scheduled batch checks instead.

Balancing Notification Frequency

Issue: Users overwhelmed by notification volume

Solutions:

1. Evaluate Real Business Need: Ask: "Does this event truly require immediate notification?" Consider: Can users check a report daily instead?

2. Increase Scenario Thresholds: Instead of notifying on ANY customer balance change, notify only when exceeding specific threshold.

3. Use LocalScope for Routine Notifications: Reserve GlobalScope for truly important alerts.

4. Implement Notification Throttling: For high-frequency events, consider custom code that limits notifications to once per hour/day per user.

📋 NOTE: Notification fatigue is real. Users who receive dozens of notifications daily will stop paying attention to all of them, including important ones. Quality over quantity.

This completes Chapter 6. Users now understand template management, import/export, troubleshooting common issues, and performance optimization.

Appendices

Appendix A: Placeholder Reference

Common Table and Field Numbers

This appendix provides quick reference for frequently-used placeholders in notifications.

Sales Header (Table 36):

Customer (Table 18):

Item (Table 27):

Purchase Header (Table 38):

💡 TIP: Field numbers are consistent across Business Central versions for standard tables (1-99999). Custom fields (50000-99999) vary by installation—always verify in your environment.

Appendix B: Glossary of Terms

Action Button: Clickable button appearing on notification toast that executes custom codeunit procedure when clicked.

Action Codeunit: AL code unit containing procedures that execute when notification action buttons are clicked.

Data Field: Key-value pair attached to notification instance providing supplementary information beyond notification text.

FlowField: Calculated field in Business Central that sums, counts, or aggregates data from related tables.

GlobalScope: Notification persistence mode where notification remains visible across page navigation until explicitly dismissed.

LocalScope: Notification persistence mode where notification appears only on current page and auto-dismisses after ~10 seconds.

Notification Action: Interactive button configuration specifying caption, codeunit ID, and procedure name.

Notification Data: Structured key-value pairs attached to notification instance containing supplementary context.

Placeholder: Syntax format [TableNo:FieldNo] that resolves to actual field value from triggering record.

Rule Engine: QUALIA Core component that monitors triggers, evaluates scenarios, and displays notifications.

Rule Group: User group assignment that filters which users receive specific notifications.

Scenario: Conditional formula that must evaluate to TRUE for notification to display.

Toast Notification: Small popup message appearing at bottom center of Business Central window.

Trigger: Configuration monitoring database table for specific events (Insert, Modify, Delete, Rename).

Trigger String: Comma-separated list of field numbers that filters which field modifications activate trigger.

Validate String: Scenario formula expression using placeholders, operators, and literals to create conditional logic.

Validation Log: System log recording all notification evaluations, trigger fires, scenario results, and display outcomes.

Appendix C: Quick Reference Guide

Creating a Notification Checklist

• Open Advanced Notifications

• Click New

• Enter Code and Description

• Enter Notification Text with placeholders

• Set Global Scope (check for persistent, uncheck for temporary)

• Add Data Fields (optional but recommended)

• Add Action Buttons (if users need to respond)

• Configure Triggers (table, events, trigger string)

• Configure Scenarios (conditional formulas)

• Assign to Rule Groups

• Save notification

• Test in sandbox environment

• Export configuration for backup

• Deploy to production

Troubleshooting Flowchart

Notification doesn't trigger:

1. Is "Enable Business Rule" checked? → If NO: Enable it

2. Does trigger match table and event? → If NO: Fix trigger

3. Do scenarios pass for test record? → If NO: Review scenario logic

4. Is user in appropriate Rule Group? → If NO: Add user to group

Notification shows wrong data:

1. Are placeholders syntactically correct? → If NO: Fix brackets/colons

2. Are table/field numbers correct? → If NO: Verify using FactBox

3. Does test record have data in those fields? → If NO: Add test data

Action button doesn't work:

1. Does codeunit exist? → If NO: Deploy codeunit extension

2. Is procedure name correct? → If NO: Fix spelling

3. Does procedure accept Notification parameter? → If NO: Update signature

4. Are required data fields present? → If NO: Add data fields

Common Placeholder Patterns

Document identification:

Order [36:3] for customer [36:79]
Invoice [36:3] amount [36:110]

Status changes:

Order [36:3] status: [36:5]
Customer [18:2] blocked: [18:39]

Threshold alerts:

Customer [18:2] balance [18:59] exceeds limit [18:27]
Item [27:3] inventory [27:99] below reorder point [27:22]

Date-based:

Order [36:3] due [36:20]
Invoice [36:3] overdue since [36:15]

Appendix D: Troubleshooting Checklist

System-Level Issues

No notifications appear for any user:

• Check Advanced Notification Setup → Enable Business Rule is checked

• Verify QUALIA Core Rule Engine is installed (version 1.1.0.4+)

• Check QUA Validation Log for any evaluation attempts

• Verify notification tables have data (Advanced Notifications list not empty)

• Test with simple notification (Insert trigger on test table)

Notifications work in sandbox but not production:

• Export from sandbox and import to production

• Verify action codeunits deployed to production

• Check custom table/field numbers match between environments

• Verify Rule Groups exist in production

• Confirm users assigned to Rule Groups in production

Notification-Specific Issues

Specific notification never triggers:

• Verify trigger Source Table No. is correct

• Check appropriate event type checked (Insert/Modify/Delete)

• Test without Trigger String (remove field filter temporarily)

• Remove all scenarios temporarily to isolate issue

• Check QUA Validation Log for this notification code

• Verify notification assigned to at least one Rule Group

• Confirm test user is in that Rule Group

Notification triggers but shows wrong data:

• Check placeholder syntax: [TableNo:FieldNo] with square brackets

• Verify table and field numbers using FactBox or Table Information page

• Test with simple placeholder like [36:3] to verify basic functionality

• Check if field has data in triggering record

• Review field data type matches expected format

User-Specific Issues

Notification works for admin but not regular users:

• Verify user in appropriate Rule Group

• Check user has "QUA Notification - View" permission set

• Confirm user has read access to trigger table

• Test with user assigned to "blank" Rule Group (all users)

• Check user account is active and licensed

Action buttons don't work for specific user:

• Verify user has execute permission on action codeunit

• Check action codeunit exists in environment

• Confirm procedure name spelling (case-sensitive)

• Test action with admin user to isolate permission issue

• Review data fields match what action code expects

Performance Issues

System slow when notifications enabled:

• Review number of active notifications (consider disabling unused)

• Check for triggers without Trigger String on high-traffic tables

• Identify FlowField scenarios on large tables

• Review QUA Validation Log for excessive evaluation frequency

• Consider consolidating overlapping notifications

Users complain about too many notifications:

• Review notification frequency in Validation Log

• Add more restrictive scenarios to filter better

• Convert frequent GlobalScope to LocalScope

• Increase threshold values in scenarios

• Consider batching notifications (daily summary vs. real-time)

Conclusion

Congratulations! You've completed the Advanced Notification User Manual. You now have comprehensive knowledge of how to create, configure, and manage notifications in Microsoft Dynamics 365 Business Central using the Advanced Notification App.

What You've Learned:

Chapter 1: System overview, prerequisites, user interface, and quick start tutorial Chapter 2: Notification creation, message composition, placeholders, data fields, and scopes Chapter 3: Interactive action buttons, action codeunits, and user-friendly design Chapter 4: Triggers, scenarios, formula syntax, and advanced patterns Chapter 5: Rule Groups, user assignment strategies, and testing Chapter 6: Template management, troubleshooting, and performance optimization

Next Steps:

1. Start Simple: Create a basic notification with one trigger and one scenario

2. Test Thoroughly: Validate in sandbox before production deployment

3. Gather Feedback: Ask users if notifications are helpful and appropriately scoped

4. Iterate: Refine messages, triggers, and targeting based on real-world usage

5. Document: Maintain configuration inventory and change log

6. Expand: Add action buttons, data fields, and sophisticated scenarios as confidence grows

Additional Resources:

• QUALIA Rule Engine Technical Design Document (for advanced architecture understanding)

• Business Central developer documentation (for action codeunit development)

• Your organization's notification standards and best practices

• QUA Validation Log (for ongoing monitoring and troubleshooting)

Support:

For technical support, customization requests, or questions about the Advanced Notification App, contact your Business Central partner or QUALIA support team.

Document Version: 1.0
Last Updated: December 2025
Published by: QUALIA Development Team

End of Advanced Notification App User Manual