Views on list pages are not just something users can create, you can also do this from AL. In this video, I show how to add views to list pages from AL.
In this video, Erik demonstrates how to use views in AL to enhance list pages in Business Central. Views allow developers to define pre-filtered, customized versions of a list page — complete with layout modifications — all within a single page object. This means fewer list pages to maintain and a richer out-of-the-box experience for users.
What Are Views in Business Central?
A view is essentially a personalized version of a list page where specific filters and layout customizations have been applied. Users in Business Central have embraced this concept enthusiastically — Erik notes that when visiting customers virtually, he sees tons of user-created views where people save their filters and use them constantly.
The great news is that as developers, we can define views directly in AL code. If we know that certain filter combinations are what users will want, we can ship those views as part of our extensions. This offers several advantages:
- Better list page experience — users get useful filtered views right out of the box
- Fewer list pages — instead of creating four different list pages, you can create one page with four views
- Low effort, high impact — adding views is minimal code that delivers significant value to users
Building the List Page
Erik starts by creating a new AL project and using the ASAL Dev Tools extension for Visual Studio Code to scaffold a list page. He highly recommends this add-on, calling it a “lifesaver” for AL development.
The base page is a customer list with a variety of fields — number, name, address, city, county, country, mobile phone, customer posting group, and email. There’s also a Customer Price Group field that is initially set to Visible = false, which becomes important later:
page 56800 "Customers with Pizzazz"
{
ApplicationArea = all;
Caption = 'Customers with Pizzazz';
PageType = List;
SourceTable = Customer;
UsageCategory = Lists;
layout
{
area(content)
{
repeater(General)
{
field("No."; Rec."No.")
{
ApplicationArea = all;
}
field(Name; Rec.Name)
{
ApplicationArea = all;
}
field(Address; Rec.Address)
{
ApplicationArea = all;
}
field(City; Rec.City)
{
ApplicationArea = all;
}
field(County; Rec.County)
{
ApplicationArea = all;
}
field("Country/Region Code"; Rec."Country/Region Code")
{
ApplicationArea = all;
}
field("Mobile Phone No."; Rec."Mobile Phone No.")
{
ApplicationArea = all;
}
field("Customer Posting Group"; Rec."Customer Posting Group")
{
ApplicationArea = all;
}
field("E-Mail"; Rec."E-Mail")
{
ApplicationArea = all;
}
field("Customer Price Group"; Rec."Customer Price Group")
{
ApplicationArea = all;
Visible = false;
}
}
}
}
}Adding Views in AL
Views are defined in a views section that goes after the layout section. Each view is declared with the view keyword and needs a name, a caption, and typically a filter definition.
View 1: Blocked Customers
The first view filters the list to show only blocked customers. The filter uses a where clause, just like table filters elsewhere in AL:
view(Pizzazz1)
{
Caption = 'Blocked Customers';
Filters = where(Blocked = filter(All | Invoice | Ship));
SharedLayout = false;
layout
{
modify(Address)
{
Visible = false;
}
modify(City)
{
Visible = false;
}
moveafter("No."; "Mobile Phone No.")
}
}This view does more than just filter — it also modifies the layout. The key property that enables this is SharedLayout = false. By default, views share the layout with the base page. If you try to add a layout section without setting SharedLayout = false, you’ll get a compiler error.
Once SharedLayout is set to false, think of the layout section inside the view as a page extension. You can:
- Modify field properties (like hiding columns with
Visible = false) - Move fields to different positions (using
moveafterormovebefore)
In this example, the Address and City columns are hidden, and the Mobile Phone No. field is moved right after the No. field. The reasoning? If a customer is blocked, you probably want their phone number front and center so you can call them right away.
View 2: Customers with Price Groups
The second view demonstrates how to reveal a hidden column in a specific view. The Customer Price Group field is defined on the base page with Visible = false, so it doesn’t appear in the default view. But in the filtered view, it’s made visible and repositioned:
view(Pizzazz2)
{
Caption = 'Customers with price groups';
filters = where("Customer Price Group" = filter(<> ''));
SharedLayout = false;
layout
{
modify("Customer Price Group")
{
Visible = true;
}
moveafter("No."; "Customer Price Group")
}
}An important constraint to note: you cannot add new columns to a view that aren’t already part of the page’s dataset. If you want a field to appear in a view, it must be defined as a field in the base page’s repeater — you can simply set it to Visible = false on the base layout and then toggle it to Visible = true in the view. This is exactly the pattern used here with the Customer Price Group field.
The Complete Source Code
Here’s the full page object with both views defined:
page 56800 "Customers with Pizzazz"
{
ApplicationArea = all;
Caption = 'Customers with Pizzazz';
PageType = List;
SourceTable = Customer;
UsageCategory = Lists;
layout
{
area(content)
{
repeater(General)
{
field("No."; Rec."No.")
{
ApplicationArea = all;
}
field(Name; Rec.Name)
{
ApplicationArea = all;
}
field(Address; Rec.Address)
{
ApplicationArea = all;
}
field(City; Rec.City)
{
ApplicationArea = all;
}
field(County; Rec.County)
{
ApplicationArea = all;
}
field("Country/Region Code"; Rec."Country/Region Code")
{
ApplicationArea = all;
}
field("Mobile Phone No."; Rec."Mobile Phone No.")
{
ApplicationArea = all;
}
field("Customer Posting Group"; Rec."Customer Posting Group")
{
ApplicationArea = all;
}
field("E-Mail"; Rec."E-Mail")
{
ApplicationArea = all;
}
field("Customer Price Group"; Rec."Customer Price Group")
{
ApplicationArea = all;
Visible = false;
}
}
}
}
views
{
view(Pizzazz1)
{
Caption = 'Blocked Customers';
Filters = where(Blocked = filter(All | Invoice | Ship));
SharedLayout = false;
layout
{
modify(Address)
{
Visible = false;
}
modify(City)
{
Visible = false;
}
moveafter("No."; "Mobile Phone No.")
}
}
view(Pizzazz2)
{
Caption = 'Customers with price groups';
filters = where("Customer Price Group" = filter(<> ''));
SharedLayout = false;
layout
{
modify("Customer Price Group")
{
Visible = true;
}
moveafter("No."; "Customer Price Group")
}
}
}
}Users Can Build on Your Views
An important point Erik highlights is that views you define in AL don’t lock users out of further customization. Users can still go in and create their own views, and they can even make personal copies of the developer-defined views and customize them further. Your views serve as a great starting point that users can build upon.
Key Takeaways
- Views are defined in a
viewssection after the page layout - Each view can have a Caption, Filters, and optionally a custom layout
- Set
SharedLayout = falseto enable layout modifications within a view - Layout changes work like a page extension — you can
modifyproperties andmoveafter/movebeforefields - You cannot add new fields in a view — fields must exist in the base page’s dataset (use
Visible = falseto hide them by default) - Views reduce the need for multiple list pages, consolidating different perspectives into a single object
- It’s a low-effort, high-impact technique — a few lines of code can significantly improve the user experience
If you’re building apps for Business Central, consider where views might make sense. They’re an easy way to add significant value for your users with minimal development effort.
