Migrating from legacy views to modern views

Modern views were introduced with Business Central April 2019 release wave and are the recommended design going forward. Legacy views are list views that were created by developers in previous versions of Business Central by placing them on the Role Center page object. Business Central displays legacy views side by side with modern views directly on the list page. But legacy views offer a degraded experience and fewer options compared to modern views.

How can developers migrate to modern views?

If your solution or customizations use legacy views, it's recommended you migrate your code to modern views before any environments are upgraded to version 23. To plan your approach, consider that legacy views originate from two distinct sources:

1. Role center actions

   These actions are defined in the area(sections), area(embedding), and area(processing) sections of the code. The actions run a list page and specify filters or sorting by using the RunPageView. Developers must remove legacy views from role center page code, and reimplement them as modern views on the target list page instead.

   The following code illustrates the AL code pattern on role center pages to look for and replace:

   actions
    {
        area(sections|embedding|processing)
        {
            action(<action_name>)
            {
                Caption = '<page_caption>';                
                RunObject = Page "<page_name>";
                RunPageView = <filters_and_sorting>;
   
   

   For example, here's a code snippet of a role center page action that adds a legacy view on the Sales Order List page:

   actions
    {
        area(embedding)
        {
            action(SalesOrdersShptNotInv)
            {
                Caption = 'Shipped Not Invoiced';
                RunObject = Page "Sales Order List";
                RunPageView = WHERE("Shipped Not Invoiced" = CONST(true));
            }
   

2. Role Center cue tiles

   When you add a cue to a Role Center and the cue's value is based on a filtered list, a view based on the filters is automatically included on the list page. This behavior is done for backwards compatibility purposes. For example, a cue on the Sales Order Processor role center that displays delayed orders will also display a legacy view named Delayed on the Sales Orders list page. Microsoft will remove backward compatibility with version 23. If these automatically created views are valuable, we recommend developers implement them as modern views on the target list page.

   The following code illustrates the AL code pattern that creates legacy views for role center cues. For more information about cues, see Creating Cues on Role Centers.

    table <ID> "<cue_table_name>"
    {
        fields
        {
            field(5; <cue_data_field>; Integer)
            {
                // Filters that make up the view on the drill-down page
                CalcFormula = Count("<source_table>" WHERE(<filters>));
            }
   

     page <ID> "<role_cue_page_part>"
    {
        SourceTable = "<cue_table_name>";
   
       layout
        {
            area(content)
            {
                cuegroup("<cue_group_name>")
                {
                    field(<cue_data_field>; Rec.<cue_data_field>)
                    {
                        // List page that opens from cue
                        DrillDownPageID = "<list page>";
                    }
   

Once you've identified the source of a legacy view, the next step is to recreate it as a modern view, as described at Views.

Can end-users benefit from modern capabilities before developers migrate legacy views?

Users can overcome limitations of legacy views simply by using the Save as... option to save a copy of the legacy view as a modern, personal view. Similarly, administrators can customize a user role and save the legacy view as a new role-specific view. While this method is quick and practical, it duplicates views on the list page, and doesn't convert the legacy view.

Why switch to modern views?

Benefits for developers:

• Benefit from a more declarative model where the view is implemented directly on the list page that it filters.
• Add the view only once, instead of having to add it to all Role Center pages that happen to navigate to the list page, while still being able to define role-specific views.
• Opportunity to define a unique column layout per view.
• Developers benefit from future enhancements to views.

Benefits for end-users:

• Users will be able to personalize their workspace by hiding, showing, and reordering these views in the Filter pane. Similarly, this task can be done once for all users of a particular role.
• The user experience is simple and consistent when the list page doesn't contain a mix of legacy and modern views, and performance is improved slightly.
• Users receive a consistent choice of views no matter how they navigate to the list page: from the Role Center navigation menu, by searching for the page, through a browser favorite or shared link, or on other form factors.
• Customers benefit from future enhancements to working with views.

Related information

List Views FAQ
Business Central April '19 release plans - List Views
Business Central April '19 release plans - Save and personalize list views
AL Development Environment
Developing Extensions