Use the built-in designer to write your pageextensions

One of the oldest features of AL is the use of the web-client-based Designer to generate pageextension objects. In this video I show how to use it, check it out:

https://youtu.be/dORP0tt-ibg

When Microsoft introduced AL as the development language for Business Central, they knew that moving from the C/SIDE visual development environment to a purely text-based coding experience would be a significant adjustment for many developers in the channel. To ease this transition, they built in a powerful feature from the very first version of AL: the ability to use Business Central’s built-in page designer to generate AL code directly into your Visual Studio Code project. In this video, Erik demonstrates how to leverage this designer to write page extensions without hand-coding every field move, addition, or removal.

Setting Up Your Environment

Erik starts with a brand new, empty AL extension project in Visual Studio Code. The goal is to make UI changes to the Customer Card (Page 21). The first step is to configure the launch.json file to specify which page you want to open in the designer.

If you can’t remember the page number, you can look it up by browsing the base application symbols. Erik references the AL Language extension for Visual Studio Code — if you click on an .app file and don’t see the object browser, you need to install the extension. With over 100,000 installs, it’s an essential tool that gives you the ability to browse pages, tables, and other objects in the base application.

The project setup is straightforward, as shown in the app.json:

{
  "id": "5cf03cc2-18f0-4fc4-b826-122d09ef994a",
  "name": "UsingTheDesigner",
  "publisher": "Default publisher",
  "version": "1.0.0.0",
  "brief": "",
  "description": "",
  "privacyStatement": "",
  "EULA": "",
  "help": "",
  "url": "",
  "logo": "",
  "dependencies": [],
  "screenshots": [],
  "platform": "1.0.0.0",
  "application": "19.0.0.0",
  "idRanges": [
    {
      "from": 50100,
      "to": 50149
    }
  ],
  "resourceExposurePolicy": {
    "allowDebugging": true,
    "allowDownloadingSource": false,
    "includeSourceInSymbolFile": false
  },
  "runtime": "8.0"
}

Launching the Designer

To launch the designer, you can either press F6 or open the Command Palette and search for “designer” to find the Publish and Open in Designer command. This publishes your app and opens Business Central with the designer running on the specified page.

An important note appears when starting the designer from Visual Studio Code:

“When starting designer from Visual Studio Code, only the page as defined in the current extension and its dependencies are loaded. If the current user’s role center is not part of the current extension or its dependencies, starting designer in the context of this extension will fail.”

This is why Erik recommends always setting the startupObjectId in your launch.json to the specific page you want to edit. This approach avoids the “will it work or won’t it” uncertainty.

Making Visual Changes in the Designer

Once the designer is running on the Customer Card, Erik demonstrates several types of changes:

  • Moving fields: Moving “Balance Due” to be before “Balance”
  • Removing fields: Removing “Address 2” since “nobody uses Address 2”
  • Adding fields: Clicking the “+” button to add “Name 2” — which Erik considers much more useful than Address 2

Note that while making changes in the designer, nothing happens yet in Visual Studio Code — it’s just sitting there waiting.

Getting the Code Back into Visual Studio Code

When you’re done making changes in the designer:

  1. Click Stop Designing
  2. It will ask about finishing up and downloading — ignore that and just hit the X to close the session
  3. Go back to Visual Studio Code
  4. Press Alt+F6

Visual Studio Code will then fetch the changes from Business Central and generate a new AL file containing the page extension code. The generated code includes things like:

  • moveafter statements for fields that were repositioned
  • modify statements with Visible = false for removed fields
  • addafter or addbefore statements for newly added fields

A Gotcha: “Show More” Matters

Erik discovered an important gotcha during his demo: when adding a field, the designer places it relative to what’s actually visible on the page. He thought he added “Name 2” after the “Name” field, but because he hadn’t clicked “Show More” to reveal all fields, it was actually placed after “IC Partner Code” — the last visible field in that section. It’s a good idea to always click “Show More” before making designer changes so you know exactly where fields are being placed.

Iterative Changes and Smart Merging

One of the most powerful aspects of this workflow is the smart merging behavior. After the first round of changes, Erik renamed the generated page extension to something more meaningful and reorganized the file into a “Page Changes” folder. When he launched the designer again (F6) and made additional changes — like removing “Shipping Advice” and modifying an action in the “Prices and Discounts” section — pressing Alt+F6 again merged the new changes into the existing page extension object.

The AL tooling is clever enough to recognize that a page extension for that page already exists in the project, so it adds the new modifications to the same object rather than creating a duplicate. Even when Erik added yet another field (“Territory Code”), the tool recognized it belonged in the same spot as a previously added field and placed it accordingly.

This non-destructive merging works regardless of where the file sits in your project folder structure.

Working with Multiple Pages

Erik also demonstrates editing the Customer List (Page 22), which produced a separate page extension file:

pageextension 50101 PageExtension50101 extends "Customer List"
{
    layout
    {
        moveafter(Name;"Phone No.")
    }
}

However, he cautions that editing multiple pages in a single designer session can be hit-or-miss. Sometimes you can successfully navigate to another page and make changes; sometimes the designer loses track of changes or encounters conflicts — especially if there are existing personalizations on the page. When the designer detects personalizations, it will warn you and ask you to “unlock” the page, because generating code based on a personalized layout could produce incorrect AL code.

Erik’s recommendation: specify the exact page you want to customize in your launch.json and focus on one page per designer session for the most reliable results.

When to Use the Designer

Erik admits he doesn’t personally use the designer very often — as a self-described “code warrior,” he tends to just look at what needs to change and write the AL code directly. However, he acknowledges it’s a great tool in specific scenarios:

  • Making many field changes to a page: When you need to move, add, and remove multiple fields, the visual feedback is invaluable
  • Learning AL page extensions: Seeing the generated code helps you understand the syntax
  • Verifying visual layout: You can see the result of your changes immediately in the browser

Summary

The built-in designer is a bridge between the old C/SIDE visual development experience and the modern AL text-based approach. The key workflow is: set your target page in launch.json, press F6 to publish and open the designer, make your visual changes, close the designer, then press Alt+F6 to pull the generated code back into Visual Studio Code. The tooling is smart enough to merge changes into existing page extension objects non-destructively, which makes iterative development smooth. While it has some limitations — particularly around multi-page editing and personalization conflicts — it’s a valuable tool for quickly scaffolding page extension code with visual confidence.

Picture of hougaard

hougaard