Changing the CardPageId in a Page Extension – Business Central Wave 1 2025

With the release of Business Central 2025 Wave 1, Business central continues to refine and empower AL developers with more flexibility when extending standard functionality. One of the subtle but significant features is the ability to change the CardPageId in a PageExtension, giving developers greater control over navigation behavior in the application.

Why Would You Want to Change CardPageID?

Consider these scenarios:

  • Simplified Views: You’ve created a simplified version of a standard card page with only the most relevant fields for a specific user role. Now, you can easily link the standard list page to this streamlined card page for those users.
  • Custom Workflows: Your custom solution requires a specialized card page with unique actions and fields for certain data. You can now seamlessly integrate this custom card page with the existing list of that data.
  • Context-Specific Information: Depending on how a user navigates to a list page, you might want them to land on a different, more contextually relevant card page.

Let’s say you’ve built a custom card page for customers that shows additional analytics or fields. You want to replace the default Customer Card when users open a customer from the list.

page 50101 "Custom Customer Card"
{
    PageType = Card;
    SourceTable = Customer;
    ApplicationArea = All;

    layout
    {
        area(content)
        {
            group("Custom Info")
            {
                field("Customer Name"; Name)
                {
                    ApplicationArea = All;
                }
                // Additional fields and logic...
            }
        }
    }
}

Then, in your page extension:

pageextension 50100 CustomerListExt extends "Customer List"
{
    CardPageId = "Custom Customer Card";
}

Now, your users will be directed to the Custom Customer Card page instead of the standard one.

The ability to change the CardPageID in page extensions in Business Central Wave 1 2025 is a significant step forward in providing developers with more control over the user interface. This seemingly small change unlocks a wealth of possibilities for creating more tailored, efficient, and user-friendly Business Central solutions.

Stay tuned for more updates.

SessionInformation.Callstack() in Business Central

Introduced in Business Central Wave 1 2025 releases, the SessionInformation.Callstack() method is a powerful diagnostic tool that helps developers trace the current call stack within AL code. Whether you’re troubleshooting custom extensions, tracking errors, or building telemetry, this method can become your best friend.

What is the SessionInformation.Callstack() Method?

The SessionInformation.Callstack() method is a built-in function in AL that returns a text string representing the current call stack of the Business Central server session. Think of the call stack as a chronological list of the functions and procedures that have been called to reach the current point in your code.

Each entry in the call stack typically includes:

  • Object Type and Name: The type of object (e.g., Codeunit, Table, Page) and its name.
  • Function/Procedure Name: The specific function or procedure being executed.
  • Line Number: The line number within the function/procedure where the call originated.

📌 Syntax

var
    CallStackText: Text;
begin
    CallStackText := SessionInformation.Callstack();
end;

🧩 Why is the Call Stack Important?

Understanding the call stack is crucial for several reasons:

  • Debugging: When an error occurs, the call stack provides a trace of the execution path leading up to the error. This helps you pinpoint the exact location where the issue originated and understand the sequence of events that triggered it.
  • Error Handling: By capturing and logging the call stack when an error occurs, you can provide more context to administrators or support teams, making it easier to diagnose and resolve issues.
  • Code Understanding: Analyzing the call stack can help you understand the flow of execution in complex codebases, especially when working with unfamiliar code or trying to understand how different modules interact.

You can combine this with

  • ErrorInfo object (for AL error handling)
  • SessionInformation.UserId() or CompanyName() for full diagnostic logs
var
    CallStack: Text;
    ErrorData: ErrorInfo;
begin
    if not TryMyFunction() then begin
        GetLastError(ErrorData);
        LogToTable('Error: %1 - Stack: %2', ErrorData.Message, SessionInformation.Callstack());
    end;

SessionInformation.Callstack() is a small method with big potential. It’s the AL developer’s X-ray — revealing the path of execution in complex customizations or tangled logic.

Use it smartly, especially in:

  • Error handling routines
  • Long-running jobs
  • Telemetry and diagnostics pipelines

Stay Tuned for more updates