Regain control of your design extensions

In this video, I show how to start aggregating your design extensions into a single extension that’s managed with Visual Studio Code. This is a great way for customers consultants to get started with development and a great method for customers to organize the chaos.

https://youtu.be/O-1Nw2vLi1E

In this video, Erik demonstrates how to regain control over the proliferating design extensions that accumulate in a Business Central environment. When users use the built-in “Design” mode to customize pages, each design session creates a separate extension — and over time, this can result in a cluttered and hard-to-manage list. Erik walks through the process of consolidating all those scattered design extensions into a single, well-organized extension managed through Visual Studio Code.

The Problem: Design Extension Sprawl

Business Central includes a built-in “Design” feature that allows users to add fields, move elements around, and customize pages visually. When a user saves their changes, the system creates a new extension. The problem is that each design session can generate a separate extension, and over time you end up with a long list of these one-off extensions cluttering your environment.

Erik demonstrates this by opening the Design mode, adding a “Budget at Date” field to the Chart of Accounts page, and saving it as an extension with a whimsical name. When he navigates to the Extensions management page, there are already multiple design extensions — some with questionable names and spelling — all stacking up.

In real-world scenarios, customers who have been using Business Central for a while can accumulate a significant number of these small extensions. At some point, just managing and understanding what’s installed becomes problematic.

The Solution: Merge Into a Single Extension

The approach Erik demonstrates is straightforward:

  1. Create a new, clean AL extension project in Visual Studio Code
  2. Download the source code from each design extension
  3. Extract the AL files into the new project
  4. Clean up and consolidate the code
  5. Uninstall the old design extensions
  6. Deploy the new consolidated extension

Step 1: Create a New Extension Project

Erik starts by creating a new AL extension project in Visual Studio Code using the standard AL:Go! command, and connects it to his Business Central tenant. The project gets its own app.json with a defined ID range:

{
  "id": "73f22305-4996-4573-813c-dba67e788239",
  "name": "Regain",
  "publisher": "Default publisher",
  "version": "1.0.0.0",
  "brief": "",
  "description": "",
  "privacyStatement": "",
  "EULA": "",
  "help": "",
  "url": "",
  "logo": "",
  "dependencies": [],
  "screenshots": [],
  "platform": "17.0.0.0",
  "application": "17.0.0.0",
  "idRanges": [
    {
      "from": 50000,
      "to": 50049
    }
  ],
  "contextSensitiveHelpUrl": "https://Regain.com/help/",
  "showMyCode": true,
  "runtime": "6.0"
}

Step 2: Download Source from Design Extensions

In the Extensions management page, each design extension has a three-dot menu with a “Download Source” option. This downloads the actual AL source code that was generated by the visual designer. Each download comes as a ZIP file containing an AL file, an app.json, and a VS Code launch configuration.

The key point: you only need to extract the .al files. The app.json in each ZIP defines that singular design extension, but you already have your own app.json in the new project. Don’t overwrite it.

Step 3: Clean Up the Generated Code

The code generated by the designer works, but it’s not pretty. Erik identifies several issues that need cleaning up:

  • Object numbers out of range: The designer-generated extensions may use object numbers outside your new extension’s ID range. You need to either renumber the objects or adjust the idRanges in app.json.
  • Cryptic field names: The designer appends random numbers to field control names (e.g., "Name 217256") to ensure uniqueness. These should be renamed to something meaningful like "Name 2 Ctl".
  • Missing Rec. prefix: The generated code uses implicit record references (e.g., just "Name 2" instead of Rec."Name 2"). Future versions of AL will require the explicit Rec. prefix. Erik notes that perhaps Microsoft should generate the code this way themselves.
  • Unhelpful page extension names: Rename them to something descriptive like “My Customer List” instead of whatever the designer generated.
  • File names: Rename the files to match the objects they contain for better organization.

Erik also recommends using F2 (rename) in Visual Studio Code rather than editing names inline, because if other code references the page extension name, the rename operation will update those references too.

The Cleaned-Up Result

After consolidation and cleanup, Erik has four clean page extension files. Here’s what they look like:

Customer List.al — adds the “Name 2” field after the Name column:

pageextension 50000 "My Customer List" extends "Customer List"
{
    layout
    {
        addafter(Name)
        {
            field("Name 2 Ctl"; Rec."Name 2")
            {
                ApplicationArea = All;
            }
        }
    }
}

Vendor List.al — similarly adds “Name 2” to the vendor list:

pageextension 50001 "My Vendor List" extends "Vendor List"
{
    layout
    {
        addafter(Name)
        {
            field("Name 2 Ctl"; Rec."Name 2")
            {
                ApplicationArea = All;
            }
        }
    }
}

My Item List.al — adds two fields to the item list, “No. 2” and “Search Description”:

pageextension 50002 "My Item List" extends "Item List"
{
    layout
    {
        addafter("No.")
        {
            field("No. 2 Ctl"; Rec."No. 2")
            {
                ApplicationArea = All;
            }
        }
        addafter(Description)
        {
            field("Search Description Ctl"; Rec."Search Description")
            {
                ApplicationArea = All;
            }
        }
    }
}

Chart Of Accounts.al — adds “Budget at Date” and “Budgeted Amount” after the Net Change column. Note that Erik added the “Budgeted Amount” field directly in Visual Studio Code, demonstrating how easy it is to make additional customizations once you have the code under your control:

pageextension 50003 "My Chart of Accounts" extends "Chart of Accounts"
{
    layout
    {
        addafter("Net Change")
        {
            field("Budget at Date Ctl"; Rec."Budget at Date")
            {
                ApplicationArea = All;
            }
            field("Budgeted Amount"; Rec."Budgeted Amount")
            {
                ApplicationArea = All;
            }
        }
    }
}

Step 4: Uninstall Old Extensions and Deploy

Before deploying the new consolidated extension, go back to the Extensions management page and uninstall all the old design extensions. Then use Shift+Ctrl+B to build the project and F5 to deploy.

After deployment, the Extensions page shows all the old design extensions as “Not Installed” and the single new “Regain” extension as the active one containing all the customizations. At this point, you can also unpublish the old extensions entirely to clean things up completely.

Important Caveat: Tables Cannot Be Moved Between Extensions

Erik emphasizes an important limitation: this consolidation technique only works for non-table objects. If a design extension has added table fields (as opposed to page fields displaying existing table fields), you cannot simply move that table extension from one extension to another. Table fields are bound to their specific extension, and moving them to a different extension creates new fields — the data will not transfer automatically. This is a critical consideration when planning any consolidation effort.

Going Forward

Once you have your consolidated extension in Visual Studio Code, you have several advantages:

  • Source control: You can track all changes properly.
  • Easy modifications: Adding new fields or making changes is straightforward in AL code, as demonstrated when Erik added the “Budgeted Amount” field.
  • Ongoing consolidation: If users continue to use the designer, you can periodically download their design sources, merge them into your main extension, and remove the one-off design extensions.
  • Learning opportunity: This workflow is a great way to get started with AL development — make changes visually in the designer, download the source, and study what the system generated.

Summary

Design extensions in Business Central are convenient for quick changes, but they can quickly spiral out of control in a production environment. By downloading the source from each design extension, extracting and cleaning up the AL files, consolidating them into a single Visual Studio Code project, and redeploying as one managed extension, you regain full control of your customizations. The code becomes easier to maintain, easier to understand, and properly tracked — all while preserving the exact same functionality your users had before.

Picture of hougaard

hougaard