Problem Statement

In Dynamics 365 Business Central, there is no supported, global AL event that fires whenever a page is opened across the application. As a result, implementers and ISVs who need to execute lightweight logic “on page open” (for example, to show contextual notifications) must either:

• add pageextension triggers (OnOpenPage, OnAfterGetCurrRecord) on every relevant page, or
• subscribe to page trigger events page-by-page (e.g., OnOpenPageEvent per page object).

This does not scale for broad scenarios (dozens or hundreds of standard and custom pages), increases maintenance cost with every platform update, and makes cross-cutting UX features unnecessarily complex.

Use Cases

1. Contextual notifications on page open
2. Inform the user when the opened document requires attention (data quality, compliance, workflow, deadlines), with actions to resolve.
3. Data quality / compliance guidance (non-blocking)
4. Detect incomplete or inconsistent data and show a non-intrusive notification at the moment the user opens the relevant page.
5. Onboarding and contextual guidance
6. Trigger teaching tips or guided experience based on role/profile/context when a user opens specific pages, without modifying each page.

Proposal

Provide a supported, global AL event that is raised when a page is opened, with enough context to implement targeted, non-intrusive UX behaviors.

Suggested event signature (illustrative)

• OnPageOpened(PageId: Integer; PageCaption: Text; RecordRef: RecordRef; IsModal: Boolean; OpenedFromPageId: Integer; UserSecurityId: Guid; CompanyName: Text; ClientType: Enum "Client Type")

A minimal alternative would also be useful:

• OnAfterPageOpen(PageId: Integer; var RecRef: RecordRef)

Key requirements

• Fires once per actual page open, not on every refresh/redraw.
• Provides PageId and user/company context.
• Provides the current record context when applicable (e.g., via RecordRef and/or SystemId). If no record is available, RecordRef can be empty.
• SaaS-safe and consistent across Web client scenarios.
• Should be filterable/controllable (at least via documented patterns), so partners can restrict it to an allow-list of PageIds to minimize overhead.

Expected Behavior

• The event is raised server-side (AL) at the time the page is logically opened.
• Partners can implement one subscriber to handle broad scenarios, instead of page-by-page extensions.
• No repeated executions caused by UI refresh.
• Performance impact is minimal and predictable, especially when partners filter by PageId.

Acceptance Criteria

• A partner can write a single subscriber that:
• identifies the page (PageId) and record context (if available),
• evaluates a rule,
• sends a standard Notification (LocalScope) with actions,
• without adding pageextension triggers across many pages.
• 
  
• The event does not spam users due to refresh; it triggers once per open.
• Works reliably in SaaS.

Concrete Example

“When a user opens a document for which they have a pending approval request (Approval Entry = Open assigned to the current user or their approval group), Business Central should automatically display a notification with the standard actions Approve and Reject, executing the standard approval processing.”

Current Workarounds and Limitations

• Page triggers in pageextensions: not scalable; high maintenance across many pages.
• Page trigger event subscribers per page: still requires explicit per-page subscriptions and object management.
• Table events (OnModify/OnValidate): good for detecting issues, but do not provide “notify on page open” behavior without additional UI-specific wiring.

Value / Benefits

• Enables clean, supported implementations of cross-cutting UX features (alerting, compliance, onboarding).
• Reduces total cost of ownership for partners and customers (less per-page customization).
• Encourages best practices: central rule logic + consistent notification UX, rather than fragmented page modifications.

Compatibility and Security Considerations

• Backward compatible: introducing a new event does not change existing behavior.
• Security: subscriber code runs under the current user context and respects permissions.
• Microsoft could document a recommended anti-spam pattern (e.g., per-session de-duplication) for notifications.