Have you ever wondered how Business Central decided what fields to use when you switch a list into tiles-mode? In this video, I go explore that, show you how it works and discuss different approaches to handling “bricks”, check it out:
In this video, Erik explores a sometimes-overlooked but important feature in AL development for Business Central: field groups. He demonstrates how field groups on tables control the tile view and dropdown lookups across the entire application, and why this UI behavior being defined at the table level rather than the page level is something every developer needs to understand.
The Separation of Concerns in Business Central… Mostly
One of the things developers have come to appreciate about Business Central is the clear separation of responsibilities: pages handle the UI, codeunits serve as libraries of functionality, and tables manage the database layer. However, there’s one peculiar exception to this clean architecture — field groups — which place a UI concern directly on the table object.
Tile Views in Action
Erik begins by demonstrating the tile view on several list pages to show the contrast between well-configured and unconfigured field groups:
- Item List: When switching to tile mode, you see nice pictures along with the item number, description, price, unit, and stock level. The “tall tiles” option is also available, showing larger photos. This looks polished and intentional.
- Customer List: Tiles display photos of contacts along with customer numbers, balance information, and other key fields. The tall tile option is available here too.
- General Posting Setup: Switching to tiles here looks far less polished — you get a mix of fields including posting group codes, account numbers, and checkboxes that don’t translate well to a visual tile format. There’s no tall tile option available.
- Locations: A simple list that produces a clean, minimal tile.
The key question is: what controls which fields appear in these tiles? The answer is not the page — it’s the table.
Understanding the Brick Field Group
If you look at the Customer List page in VS Code, you won’t find anything on the page object that defines what appears in the tile view. That’s because the tile definition lives on the Customer table, in a construct called a field group.
On the Customer table, you’ll find two field groups defined:
- Brick — Controls what is displayed when a user switches to tile view
- DropDown — Controls what fields appear in lookup dropdowns
The Brick field group on the Customer table includes fields like Number, Name, Balance, Contact, Balance Due, and Image. When an image field is present in the brick, the “tall tile” option becomes available. Without an image field, only the standard tile view is offered.
This means that no matter what page you’re on — even if you’ve built a custom customer page with carefully chosen statistical fields — when a user clicks the tile view, the display is controlled entirely by the Brick field group on the table. Whatever you have done on that page doesn’t matter because the field group called Brick is the one that decides what fields to show.
What Happens Without a Field Group?
Looking at the General Posting Setup table, Erik shows that no field groups are defined. Yet a tile view is still available. What happens in this case?
Without a Brick field group defined, Business Central falls back to displaying the first five columns from the table as the brick content. This often produces an awkward or confusing tile view, as those first fields may include codes, boolean flags, or account numbers that don’t present well visually.
Erik demonstrates this by counting the fields shown in the General Posting Setup tile: the general business posting group, the general product posting group, the description, a checkbox, and an account number — exactly five fields pulled from the beginning of the table definition.
The DropDown Field Group
The other field group, DropDown (note: both D’s must be capitalized), controls what users see when they perform a lookup on a field that references that table. For example, when looking up an item number on a journal line, the columns displayed in the lookup — Number, Description, Base Unit of Measure, Unit Price — come directly from the DropDown field group on the Item table.
If you don’t specify a DropDown field group, the system will display whatever it defaults to — typically the first few fields from the table. This behavior is undefined and could potentially change between versions.
A Note on Table-Level UI Properties
Field groups aren’t the only UI-related properties on tables. Tables also support DrillDownPageId and LookupPageId properties, which define which pages open when users drill down or look up records. While these can be overridden on individual pages using OnLookup and OnDrillDown triggers, the field group definitions cannot be overridden at the page level. They are locked to the table.
This creates an important limitation: if you have different list pages on the same table showing different columns, all of them will render the same tile view based on the single Brick field group defined on the table.
Two Approaches for Your Tables
Erik outlines two strategies when creating new tables:
- Design your list columns to look good as tiles: If you’re confident your list page columns will produce a reasonable tile view, you can rely on the default behavior without explicitly defining a Brick field group.
- Explicitly define a Brick field group: This gives you control over the tile presentation, but be aware that this single definition will apply across all pages that display records from that table. If you have multiple list views with different columns, they’ll all share the same tile appearance.
Bonus: VS Code Navigation Tip
While navigating between files during the demo, Erik shares a useful VS Code keyboard shortcut: use Alt + Left Arrow and Alt + Right Arrow to navigate back and forward between locations you’ve visited in the editor. This works similarly to browser navigation and can save significant time when jumping between related table and page objects.
Key Takeaways
- Field groups are defined on tables, not pages, making them one of the few UI-related constructs that live at the data layer.
- The Brick field group controls tile view rendering. Including an image field enables the tall tile option.
- The DropDown field group (with two capital D’s) controls what appears in lookup dropdowns throughout the application.
- Without explicit field groups, Business Central defaults to showing the first five fields from the table — which often produces poor results.
- Field groups cannot be overridden at the page level, so a single Brick definition applies to all pages showing records from that table.
- When creating new tables, always consider how users will experience tile view and lookups, and define your field groups intentionally rather than leaving it to chance.
