Are you using the secret ListCard page type (or is it CardList)?

In this video, I take a look at how List and Card pages can work together, and how they affect each other. Check it out:

https://youtu.be/eIIz5VHDPlA

In this video, Erik explores a powerful but often overlooked feature in Business Central AL development: the relationship between List and Card page types when connected via the CardPageId property. While many developers create lists and cards independently and wire up their own navigation, Business Central provides built-in UI behavior when you properly connect the two — giving you what Erik playfully calls the “ListCard” (or “CardList”) page type.

Understanding Page Types in Business Central

When you create a page in Business Central, you choose from several page types: List, Card, ListPlus, Worksheet, Dialog, and more. The purpose of selecting the correct page type is to give the rendering engine the best chance of displaying the page correctly. But something interesting happens when you connect a List and a Card together — you get enhanced behavior on both sides that you wouldn’t get from either page type alone.

Starting with a Basic List

Erik starts by creating a simple customer list page using the AL dev tools page wizard. The list is straightforward — it uses the Customer table as its source and displays a handful of fields in a repeater:

page 55100 "My Customer List"
{
    ApplicationArea = All;
    Caption = 'My Customer List';
    PageType = List;
    SourceTable = Customer;
    UsageCategory = Lists;

    layout
    {
        area(content)
        {
            repeater(General)
            {
                field("No."; Rec."No.")
                {
                }
                field(Name; Rec.Name)
                {
                }
                field("Name 2"; Rec."Name 2")
                {
                }
                field(Address; Rec.Address)
                {
                }
                field("Address 2"; Rec."Address 2")
                {
                }
                field(City; Rec.City)
                {
                }
            }
        }
    }
}

When deployed, a standalone list can be rendered in a few different ways: through the Role Center, in edit mode (via “Edit List”), and in non-edit/view mode. That’s standard list behavior.

Creating the Card Page

Next, Erik creates a customer card page. The card has more fields than the list (as is typical) and is set up as its own independent page:

page 55101 "My Customer Card"
{
    ApplicationArea = All;
    Caption = 'My Customer Card';
    PageType = Card;
    SourceTable = Customer;
    UsageCategory = Administration;

    layout
    {
        area(content)
        {
            group(General)
            {
                field("No."; Rec."No.")
                {
                }
                field(Name; Rec.Name)
                {
                }
                field("Name 2"; Rec."Name 2")
                {
                }
                field("Mobile Phone No."; Rec."Mobile Phone No.")
                {
                }
                field(Address; Rec.Address)
                {
                }
                field("Address 2"; Rec."Address 2")
                {
                }
                field(City; Rec.City)
                {
                }
                field(County; Rec.County)
                {
                }
                field("Country/Region Code"; Rec."Country/Region Code")
                {
                }
            }
        }
    }
}

On its own, the card allows you to navigate between records and toggle between edit and view modes. Both pages work independently — but that’s not where the magic is.

Connecting List and Card with CardPageId

The key step is adding a single property to the list page:

CardPageId = "My Customer Card";

This one line connects the two pages, and the rendering engine immediately responds with enhanced behavior:

  • Clickable links: In the Role Center version of the list, each record now becomes a link that navigates directly to the card.
  • Enhanced menu options: Instead of just “Edit List,” you now get “Edit” (which opens the card in edit mode), “View” (which opens the card in view mode), and the original list editing capabilities.
  • New record creation: A “New” action appears that opens the card for creating a new record.

All of this comes out of the box — no custom actions, no manual page calls, no extra code.

How Card Properties Affect the List

One of the most interesting aspects Erik demonstrates is how properties set on the card page directly influence what appears on the list’s action menu. The two pages, while independent objects, work in tandem.

Making the List Non-Editable

When you set Editable = false on the list page, you can no longer go into “Edit List” mode. However, because the card is still connected, you still get:

  • A New button that opens the card for record creation
  • An Edit option that opens the card in edit mode

So a non-editable list still provides edit functionality — through the card. The list itself remains read-only, but the card handles all the editing.

Restricting Insert on the Card

Setting InsertAllowed = false on the card page removes the “New” option from the list’s menu:

page 55101 "My Customer Card"
{
    ...
    InsertAllowed = false;
    ...
}

With this property set, the list still shows Edit and Delete, but New is gone — because the card doesn’t allow inserts.

Restricting Delete on the Card

Similarly, setting DeleteAllowed = false on the card removes the Delete option from the list:

page 55101 "My Customer Card"
{
    ...
    DeleteAllowed = false;
    ...
}

The properties of the card directly dictate what actions are available on the connected list.

The Final Source Code

Here’s the final version of both pages, with the list set to non-editable and the card restricting both insert and delete:

page 55100 "My Customer List"
{
    ApplicationArea = All;
    Caption = 'My Customer List';
    PageType = List;
    CardPageId = "My Customer Card";
    Editable = false;
    SourceTable = Customer;
    UsageCategory = Lists;

    layout
    {
        area(content)
        {
            repeater(General)
            {
                field("No."; Rec."No.")
                {
                }
                field(Name; Rec.Name)
                {
                }
                field("Name 2"; Rec."Name 2")
                {
                }
                field(Address; Rec.Address)
                {
                }
                field("Address 2"; Rec."Address 2")
                {
                }
                field(City; Rec.City)
                {
                }
            }
        }
    }
}
page 55101 "My Customer Card"
{
    ApplicationArea = All;
    Caption = 'My Customer Card';
    PageType = Card;
    InsertAllowed = false;
    DeleteAllowed = false;
    SourceTable = Customer;
    UsageCategory = Administration;

    layout
    {
        area(content)
        {
            group(General)
            {
                field("No."; Rec."No.")
                {
                }
                field(Name; Rec.Name)
                {
                }
                field("Name 2"; Rec."Name 2")
                {
                }
                field("Mobile Phone No."; Rec."Mobile Phone No.")
                {
                }
                field(Address; Rec.Address)
                {
                }
                field("Address 2"; Rec."Address 2")
                {
                }
                field(City; Rec.City)
                {
                }
                field(County; Rec.County)
                {
                }
                field("Country/Region Code"; Rec."Country/Region Code")
                {
                }
            }
        }
    }
}

A Note on Edit Mode Quirks

Erik points out one minor quirk: when the card has Editable = false set, the list may still show action options like Delete that appear to be available. However, when you actually try to use them, the card blocks the operation. The UI gives you a “teaser” suggesting the action might be possible, but ultimately the card’s property restrictions take precedence. This is a small inconsistency in the rendering, but the data integrity is maintained.

Conclusion

The CardPageId property is a simple but powerful feature that many AL developers underutilize. By properly connecting a List page to a Card page, you get a wealth of built-in UI behavior for free: clickable navigation links, contextual Edit/View/New/Delete actions, and intelligent property inheritance from the card to the list. There’s no need to build custom actions or manually open pages with code — Business Central handles it all automatically. If your scenario involves a list with a corresponding card, always use this connection. You’ll get polished, consistent UI behavior straight out of the box.

Picture of hougaard

hougaard