Is it a card, is it a list? No, it’s a cardlist, listcard?

Follow me down the rabbit hole of list pages that are also card pages, or vice versa. A recent question trigger an interesting experiment resulting in hybrid pages, take a look:

https://youtu.be/iL8IekP5-DA

In this video, Erik explores what happens when you mix page controls in Business Central in ways that Microsoft didn’t intend — specifically, putting a repeater control on a card page. The result? A hybrid page that’s simultaneously a card and a list. It’s a fascinating look at the boundaries of the AL layout engine and a cautionary tale about venturing outside supported patterns.

The Layout Engine vs. The Compiler

The key insight Erik shares at the start is that the Business Central layout engine is designed to work for all the cases that Microsoft has defined — but the AL compiler is not designed to disallow all the other cases. This means you can mix and combine controls in ways that aren’t used by Microsoft, aren’t documented, and aren’t officially supported. Sometimes the results are interesting; sometimes they’re just strange.

The “Card-List” Page

The page in question looks like a customer card at first glance — the upper left corner says “My Customer Card,” and it has all the familiar fields you’d expect. But there’s one crucial difference: there’s a list of customer names embedded right on the card. Clicking a different name in the list navigates to that customer’s card data.

So what’s going on? The page type is explicitly set to Card, but a repeater control has been placed inside it — something you’d normally only see on a List page. The result is a page that behaves as both a card and a list simultaneously.

Here’s the standard customer card page for reference:

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")
                {
                }
            }
        }
    }
}

The trick to creating the “card-list” hybrid is simply wrapping one or more fields in a repeater control instead of leaving them in a group. That’s the only change needed — and the compiler is perfectly happy with it. No errors, no warnings.

It Actually Works (Mostly)

Erik demonstrates that this hybrid page is surprisingly functional:

  • Navigation works: Clicking a different customer name in the repeater switches the card to show that customer’s data.
  • Editing works: You can modify field values and they save correctly.
  • Renaming works: Even renaming a record (changing the primary key) functions as expected.
  • Tablet view: The layout renders fine on tablet form factors.
  • Phone view: This is where things get weird. On a phone, you can’t do inline editing on a table row — clicking a field tries to navigate to a pseudo-card view, resulting in a strange layout experience.

Going Even Further: Multiple Repeaters

Erik pushes the experiment further by adding a second repeater on the same card page — one around the Name field and another around the Name 2 field. Again, the compiler has no complaints. The result is two repeater lists on a single card page, both controlling the same source table.

This highlights an important technical detail: the repeater control always controls the source table of the page. Both repeaters are bound to the same Customer table, so they interact with each other. If you wanted to display a different set of data in a repeated fashion on a card page, the proper approach would be to use a page part (what used to be called a “sub page”) — a page embedded inside another page that can have its own source table.

The Companion List Page

For completeness, here’s the standard list page that pairs with the card, using the conventional approach with a single repeater on a List page type:

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)
                {
                }
            }
        }
    }
}

This is how it’s supposed to be done — a list page with a repeater, linked to a separate card page via CardPageId. Clean, predictable, and fully supported.

Here Be Dragons

Erik’s central message is one of caution. Microsoft designed all the page controls — repeaters, cue groups, fixed layouts, grids — to be used in specific scenarios. They work tremendously well within those scenarios. But the moment you venture outside that protected territory, you should see a “here be dragons” warning in your mind.

The key risks of mixing controls in unsupported ways:

  • No compiler protection: The compiler won’t warn you. There may be code analyzers that catch some of these patterns, but out of the box, you’re on your own.
  • Breakage risk: Microsoft could change the layout engine behavior in any major release, and if you’re using controls in unsupported combinations, your pages could break without warning.
  • No precedent in the base app: As far as Erik knows, Microsoft doesn’t use repeaters on card pages anywhere in the base application. If they don’t do it, it’s not being tested for, and it’s not being maintained.
  • Cross-device issues: As demonstrated with the phone layout, unusual control combinations can produce unexpected results on different form factors.

Could This Ever Be Useful?

Erik acknowledges that there might be valid use cases — for example, a page where you have a small number of records (say five choices) and you want to switch between them while editing properties, all on a single card-like interface. It’s an interesting UI pattern, but it’s firmly in “unsupported experiment” territory.

Conclusion

This exploration of the “card-list” hybrid page is a great reminder that just because the compiler allows something doesn’t mean it’s a good idea. The AL compiler is permissive when it comes to page layout combinations, giving developers rope that could easily become a noose in production. If you’re tempted to use unconventional control combinations, understand that you’re stepping outside the boundaries of what Microsoft tests and supports — and be prepared for things to break in future updates. It’s a fun experiment, but Erik’s advice is clear: probably don’t put this into production.

Picture of hougaard

hougaard