Dynamics 365 Business Central AL Development

Business Central handles finance, customers, sales orders, inventory, and invoices out of the box. But what happens when your company needs one additional field, a custom approval step, a new business rule, or functionality that doesn't exist in the standard application? In this episode of M365 FM, Mirko Peters explains Dynamics 365 Business Central AL Development—how developers use Microsoft's AL language and extensions to customize Business Central without directly modifying the standard application.
 
 WHAT IS BUSINESS CENTRAL AL DEVELOPMENT?
 AL stands for Application Language. It is Microsoft's programming language for developing functionality specifically for Dynamics 365 Business Central. AL allows developers to add and change business functionality involving records, pages, reports, calculations, validations, and processes. The important concept isn't only AL itself. It's the extension model. Instead of rewriting Microsoft's standard Business Central application, developers create separate extensions containing their custom functionality.

WHY BUSINESSES CUSTOMIZE BUSINESS CENTRAL
Business Central already covers many standard business processes. But no two organizations operate exactly the same way. A food distributor might require additional batch information. A service business could require another approval before invoicing. A retailer might need customer reward levels. Another organization could require specific fields, forms, or internal validation rules. These requirements don't necessarily justify changing an entire ERP process. Sometimes the business simply needs Business Central to understand one additional piece of information or enforce one additional rule.

WHY EXTENSIONS EXIST
Older development approaches frequently involved modifying the original application code. That could work until the underlying application was updated. Microsoft's new code and the organization's modifications then had to be compared and reconciled. Business Central extensions use a different model. The standard application remains in place while custom functionality sits beside it as a separate application. Updates still require testing, but developers don't need to recreate every customization inside Microsoft's original source code.

THINK OF BUSINESS CENTRAL AS AN OFFICE BUILDING
The episode uses an office-building analogy. Business Central is the building. Instead of knocking holes through the existing structure whenever somebody needs another room, the platform provides approved connection points for extending it. Microsoft maintains the main building. The organization maintains its additional functionality. This separation makes the resulting environment easier to understand and maintain over time.

STANDARD FIRST, CUSTOMIZE SECOND
Not everything should be customized. Changing Business Central simply because its standard process looks different from an organization's previous ERP can create unnecessary maintenance. Good customization begins with three questions: What problem are employees experiencing? What should happen instead? Can standard Business Central already solve it? AL development becomes relevant when the standard product genuinely doesn't meet the business requirement. 

WHAT CAN AL DO?
AL can work with Business Central data and application behavior. Developers can use it to add or change records, calculate values, control pages, create reports, validate information, display messages, and automate business rules. But AL isn't intended as a general-purpose language for building every kind of software. You wouldn't normally choose AL for a public shopping website, mobile game, or standalone desktop application. Its focused job is extending Dynamics 365 Business Central.

WHAT IS A BUSINESS CENTRAL EXTENSION?
An extension is a separate application Business Central can install. It contains the organization's custom

Welcome to another episode of Microsoft Knowledge Nuggets.

I'm your host, Mirko Peters.

So here's the scenario.

You're working in Business Central

and you need one small change.

Maybe an extra field on a customer record,

a different approval step,

or a rule that checks an order before someone posts it.

Then someone brings up AL, extensions,

tables, pages, and code units,

and suddenly that small request sounds like a whole new language.

It's a language, sure, but it doesn't have to feel mysterious.

Think of Business Central as an office building.

AL gives developers the instructions to add a room, a form,

or a new rule without knocking holes through the building itself.

That's the knowledge nugget for today.

By the end of this episode,

you'll know what AL development means, why extensions exist,

and how custom work fits into Business Central.

Why Businesses Customize Business Central?

Business Central already handles a lot of daily worker finance,

customers, sales orders, stock invoices,

all in one connected system instead of a pile of spreadsheets

and separate tools.

For many companies, that standard setup covers most of the job.

But here's the thing, no two companies work the same way.

Take a food distributor needing batch details,

another company never uses,

a service business requiring a special approval process

before invoicing, a retailer wanting reward levels for discounts,

and someone else needing a form with their own wording,

fields, and internal rules.

The business won't change its ways for one missing field,

and you don't want every small request

to turn into a risky change to the whole system either.

That used to be a bigger problem.

In older systems,

developers opened the original code and edited it directly,

and it worked until the next update arrived.

Then the company had Microsoft's new version on one side,

its own changes on the other,

and someone had to reconcile everything

before the update could move forward.

Picture an office where every tenant runs new cables

through the walls without a plan.

It works for a while, but when the building needs repairs,

nobody knows which cable belongs to whom.

Business Central takes a different route.

Instead of rewriting the standard application,

developers build a separate add-on that connects to it,

keeping the standard part in place

while the company's own changes sit beside it

and work through supported points in the system.

That separation matters when updates arrive

because Microsoft updates its part of the building

while the custom works stays in its own space.

There are still tests and fixes, software changes after all,

but the developer isn't expected to copy and rework

every change inside Microsoft's original code.

So what does a business actually customize?

The customizations add data.

The standard system doesn't store like delivery instructions

and internal risk score, a membership level,

or a link to an outside system,

and they add screens that guide staff

through a task in the right order.

They also enforce rules like stopping an order

when a required document is missing.

Custom work also helps people avoid manual steps.

Imagine staff copying customer data from business central

into another tool every Friday,

checking conditions by hand,

then sending a report to a manager.

A well-built change keeps that information in business central,

applies the rule consistently,

and gives staff a button or page that fits their daily work.

Let's clear up a myth.

You don't want to customize everything.

Standard business central already has many processes built in,

changing something just because it looks different

from an old system creates extra work later,

so good custom work starts with a clear business reason.

What problem are people facing?

What should happen instead?

And can the standard product already do it?

When the standard product doesn't meet that need,

AL enters the picture.

AL focuses on business central itself,

reading, adding, and changing records at the database level

while controlling what happens on pages, reports,

and other parts of the application,

and it calculates values, moves data,

and shows messages when rules fail throughout processes.

That's a lot of work for one language,

but AL isn't a general tool for every type of software,

and you wouldn't choose it to build a public shopping website,

a mobile game, or a standalone desktop app.

AL exists for one focused job,

shaping the data and behavior inside business central,

so the system matches how a company operates,

and that's exactly what we'll look at next.

AL in extensions, the safe add-on model.

AL stands for application language.

It's Microsoft's programming language for business central,

and it gives developers a structured way

to create new business functions

or change how existing parts of the system behave.

But the word extension is just as important as AL.

An extension is a separate app that business central can install.

It holds the company's custom work

while the standard business central application stays untouched.

Think of it less like rewriting a handbook

and more like adding approved pages to it.

O pages that follow the original rules without erasing them.

That might sound like a technical detail,

but it changes how custom work lives over time.

Imagine a company needs a new office room for a special team.

The old approach meant breaking through a wall

in the main building and changing the structure itself.

It might solve the need today,

but future repairs become a nightmare

because the original building no longer matches its blueprints

and extension works differently.

The building already has doors, power points,

and rules for adding space.

You build the new room through those approved connections,

the room belongs to the company,

but the main building can still receive maintenance

without tearing apart every custom wall.

That's exactly how business central extensions work.

The base application contains the standard work Microsoft supplies.

An extension can add its own fields,

screens, buttons, rules, reports, and even links to other systems.

It can react when certain business actions happen,

but it does this through supported ways

of connecting to the standard application.

So boundaries are built in.

That's a good thing.

Without boundaries, a small custom request

can reach deep into areas it shouldn't touch.

With extensions, the developer works

with clear object types and defined connection points.

That makes the code easier to understand

when someone else needs to read it later.

This approach also fits the cloud version

of business central perfectly.

Microsoft updates the service regularly.

A company still needs to test its extension after changes,

especially if it depends on parts of the product

that have changed.

Software never removes the need for care.

But keeping custom code separate lowers the chance

that every update turns into a major rebuild of old modifications.

You may hear people mention CAL when they talk

about older dynamics nav systems.

CAL came from an earlier development model

where developers often change the original application objects

directly.

Many companies ran successful systems that way for years.

But it tied custom work much more closely to the standard code

and updates required a lot of comparison and repair work.

AL moved business central toward app-based development.

That doesn't mean every extension is large or complicated.

One extension might only add a feel to a customer record

and show it on a familiar screen.

Another might contain a full solution

for a particular business type

with its own records, processes, pages, and reports.

Both follow the same basic idea.

The custom app lives beside business central instead

of hiding a rewrite of it.

You can also install more than one extension.

A company might use an extension from a software partner,

for payroll, another for shipping,

and a small internal extension for rules

that only matter to that company.

Business central brings them together in the same working

system as long as they follow the platform's rules

and don't conflict.

So AL isn't just a way to write code.

It's the language developers use to create these add-on apps.

And extensions are the container that

carries those changes into business central.

That model lets the company tailor the system

while keeping the standard product recognizable

and easier to maintain.

Now let's open one of these extensions

and look at the building blocks inside it.

The main AL building blocks inside an AL extension

developers work with objects.

An object is one named piece of the app

with a clear job, like storing information,

showing a screen, running a rule, or producing a document.

Once you see those jobs separately,

AL starts to feel much less like a wall of code.

Let's start with the place where business information lives.

Table store data in business central.

Think of a table as a digital filing cabinet

for one type of record.

One cabinet might hold customers, another holds items,

and another holds sales orders.

Each record is one file inside that cabinet.

A customer table contains one record for each customer.

An item table contains one record for each product.

If your company needs information

that standard business central doesn't store,

an extension can create its own table AU,

maybe for reward levels, equipment inspections,

or project approvals.

These fields are the labeled spaces inside each record.

A customer record can include a name,

an address, a payment term, and a phone number

because the customer table contains fields

for those details.

Fields can hold text, dates, amounts, yes or no answers,

or a choice from a fixed list.

A field can also point to another record.

For example, a customer could contain a reward ID field.

Instead of typing any random text,

staff select a reward level from a separate reward table.

That link keeps the data clean

because everyone chooses from the same known list.

So tables hold the facts.

But how do people see and work with those facts?

Pages.

A page is the screen you open in business central.

The customer card is a page.

A list of sales orders is a page.

A page controls what users can view, enter, search for,

and act on.

Different pages fit different jobs.

A cart page focuses on one record at a time

like one customer or one item.

A list page shows many records in rows,

which works well when you need to scan, filter,

or find something quickly.

A worksheet page supports work

where people enter or process several lines

of information together.

The table stores the information.

The page puts it in front of the user.

That separation is helpful because you can change the screen

without changing where the data lives,

or reuse the same table on more than one page

when different teams need different views

of the same records.

Now, what if the data already belongs

on a standard business central record?

You usually don't create a replacement customer table

just because you need one extra field.

You use a table extension.

A table extension adds your field

to the existing customer table.

The standard customer record stays where it belongs.

While your extension adds the company's specific detail

beside the standard fields.

That might be a reward ID, a delivery note,

an account manager, or a field that connects

to another part of the business.

But adding the field to the table

doesn't automatically put it on the screen.

For that, you use a page extension.

A page extension adds a field, group, or action

to an existing page.

If the business needs staff to choose a reward level

while viewing a customer, the page extension

can place the reward ID field on the customer card,

right where staff already work.

That keeps the experience familiar.

Instead of sending users to a separate custom screen

for a simple detail, the extension adds the detail

to the page they already know.

A page extension can also add an action on us, a button,

or a menu command that starts a task.

For example, a customer card could include a reward action

that opens the reward list.

Behind the screen, you need a home for the business rules.

That home is often a code unit.

A code unit contains AL procedures, which

are named pieces of code that do a particular job.

Think of it as the back office team that

handles a task when a page report or another process

asks for help.

Suppose the reward level decides which discount

applies to a customer.

The discount calculation belongs in a code unit,

not in the customer card page itself.

Then a sales process, a report, or a future page

can use the same rule without copying it into several places.

One rule, one place to maintain it.

Business Central also includes other object types

for different jobs.

Reports collect data and present it in a document or layout

like an invoice or a sales report.

Queries ask focused questions across data,

a U, which customers order the certain item during a period,

for example, XML ports help bring data in or send it out

in a structured format, often when another system needs

to exchange information with Business Central,

put those pieces together and you can picture

a small customer rewards extension.

A reward table stores each level and its discount percentage.

Reward pages let staff manage those levels.

A customer table extension adds a reward ID to each customer

while a customer card page extension displays it.

A page action opens the reward list

and the code unit calculates the discount rule.

Each object handles one part of the job.

That makes the extension easier to read, test, and change

when the business rule changes six months later.

But a business rule often needs to run at exactly the right moment

such as when someone posts an order.

That's where triggers and events come in.

Events triggers and business rules.

Welcome back to another knowledge nugget.

I'm Mirko Peters and today we're breaking down events,

triggers, and business rules in Business Central

so you've added a customer reward field.

Good, here's the real question.

When should Business Central actually use that field?

Imagine you're about to post a sales order.

Before the system creates the final entries,

you want one extra check.

Maybe the customer needs an approved reward level

before a discount kicks in.

Or maybe a required delivery document must exist

before the order can move forward.

You want that check at the right moment.

But you don't want to copy the entire sales posting process

into your own extension just to add one rule.

That process already handles a lot behind the scenes.

If you copy it, your extension is now stuck

maintaining all those future changes, not ideal.

So AL gives developers a few ways to run code.

Which one you pick depends on what needs to happen.

First up, triggers.

A trigger is a name spot inside an AL object

where code can run.

When someone changes a value on a table field,

the trigger fires code.

When a page opens or closes the trigger fires code,

reports, queries, XML ports, tables, extensions, AL,

they all have these spots where a developer can add rules.

Take the reward ID field on a customer.

When a user picks a reward level, a validation trigger can run.

The code checks is the customer blocked.

Does the reward level exist?

Does another field need an update?

The check happens right when the value changes.

Not later when someone discovers a mistake.

Triggers work well when the rule belongs closely to that object.

But Business Central also uses events.

An event is like a notice.

One part of the application sends it when something happens.

It might announce that a record is about to be inserted

or that a document is about to post.

Or that a process has finished, your extension

can listen for that notice.

The code that listens is called an event subscriber.

It waits for a specific named event.

When Business Central raises that event,

the subscriber runs its own procedure.

The standard process stays in charge.

For example, when Business Central begins posting a sales order,

it raises an event before continuing.

Your reward's extension receives that notice.

It checks the customer's reward ID and discount rule.

Then it either allows the process to continue

or stops it with a clear message.

The standard posting process still belongs to Business Central.

Your extension just adds its company-specific rule

at that connection point.

You'll often hear event names like on before or on after.

On before means your code runs before an action finishes.

That's perfect for a check that can prevent the next step,

oh, like stopping a sales order if a condition fails.

After means the action already happened,

you can react, create a related record, update a note,

or start another piece of work.

The names tell you the timing and timing matters.

A rule that runs after posting can't prevent it.

A rule that runs too early may not have the data it needs.

So developers pick the event based

on what the business rule must do and when.

Code can also start from an action.

A user clicks a button like check reward status

and that action calls a procedure.

Code can also run when one object calls another through a variable

that sounds technical, but it's simple.

One part of the extension asks another to perform a job.

Variables help with that.

A variable is a named place that holds a value while code runs.

It could be a number, text, a date,

or even a business central record like the current customer.

In AL, you declare them with var.

For example, a rewards procedure might use a variable

called customer to hold the current customer record.

Another variable called discount percent holds

the discounted fines.

These aren't permanent records.

They're just working values for that piece of code.

Here's the thing about where code lives.

If a rule might be used from more than one place,

put it in a code unit.

That way, the customer card, a sales process, and a report

can all call the same discount procedure

instead of each having its own version.

That avoids a familiar problem.

One screen applies a 10% discount, another applies 5%,

and nobody knows which rule to trust.

Keeping shared business rules in one code unit

gives the extension one source for that decision.

So triggers handle rules close to an object,

events let an extension react to business central's own processes.

Code units keep shared logic together.

Once those pieces connect, the next question is,

where do developers write, test, and inspect all this AL code?

Or where AL development happens,

AL development usually happens in Visual Studio Code.

A-U often called VS Code.

It's your workspace for writing AL files.

It keeps your extension organized.

It helps you find problems.

And it sends the finished app

to a business central environment for testing.

But VS Code on its own is just a general code editor.

It needs the AL language extension from Microsoft.

That extension teaches VS Code how business central works.

It can suggest object names as you type.

It points out errors before you publish.

It helps you browse fields and procedures.

And it connects your project to a business central environment.

That saves a lot of guesswork.

When you start a new AL project, you can run the command AL.

Go inside VS Code.

It creates the basic project folder and settings files

A-U extension name, publisher, version,

and which business central environment to use.

Think of that project folder as the extensions workbench.

Each AL file belongs there.

One file might hold a table.

Another appage extension, a code unit can have its own file.

That way, when someone opens the project,

they can find the right part without scrolling

through one huge document.

When the code is ready to test,

VS Code compiles it into an app package.

That's the installable version of the extension.

Business central reads that package

and adds the extension to the environment.

If there's a missing field, a spelling mistake,

or any problem that prevents the app from building,

VS Code tells you before the package ever reaches business central.

Testing should happen in a sandbox first.

A sandbox is a separate business central environment

where you can try changes without risking live business work.

You publish the extension, you open the pages,

it changes, you enter test records,

and you see if the rules work as expected.

That separation matters.

You don't want to discover that a new validation rule

blocks sales orders while staff are trying to do their jobs.

In a sandbox, you can make mistakes,

remove test data, change code, and publish again

without affecting live records.

Sometimes the code runs, but the result still looks wrong.

That's when debugging helps.

You place a breakpoint in the code, start the process,

and the extension pauses while it runs.

At that pause, you can inspect values AL,

like the current customer, the selected reward level,

or the discount percentage the procedure calculated.

Instead of guessing why a rule failed,

you can see exactly what the code received.

Development teams also use Git to keep a history of their work.

Git records changes to the project files over time.

If someone changes a rule and introduces a problem,

the team can compare versions, see what changed,

and revert if needed.

It also helps when more than one developer works

on the same extension.

For a beginner, the best path is to start small.

Learn your way around business central first.

Then create one table and one page.

After that, extend a standard page, add a simple business rule,

and learn how events and install data fit into the project.

Next, let's connect those pieces through one small add-on

a business could actually use.

A simple example, building a customer rewards add-on.

What does a real AL extension actually look like?

Let our thumbs dive into a simple example.

Imagine your company wants customer reward levels,

each with its own discount.

You start by creating a reward table.

Think of it as a digital filing cabinet, where each file

holds an ID, a description, and a discount percentage.

Gold gets 10% off, for instance.

Your staff need to manage those levels

without touching technical tools.

So you add two pages, a reward list page

to see all levels and a reward card page to edit or create one.

They can add a new level, adjust a percentage,

or review what's there or, or without opening

any development environment.

Next, you extend the customer table

with a new field called reward ID.

That field links each customer to one reward record.

And you place that field right on the customer cart

page where staff already manage customer details,

then you add a reward action so they can open the reward list

directly from that same cart.

The discount rule itself lives inside a code unit.

When another process needs a customer's discount,

it calls that code unit instead of calculating it over

and over on every page.

That's efficient.

An install code unit adds starter reward levels.

The first time your extension is installed.

And an event subscriber checks the chosen reward level

during a sales process, applying your company's

rule at exactly the right moment.

That's one small extension, but notice what it contains.

Data tables, user screens, navigation actions,

setup logic, and business rules are all working together.

That's the real power of AL.

Well, conclusion, your AL development starting point.

So here's the takeaway.

AL development lets you add the specific features

your company needs to business central

without touching the core application.

And you don't have to build everything at once.

Start with one field, one page extension,

and one clear rule.

That's your first building block.

If you found this knowledge nugget helpful,

subscribe on your favorite podcast platform

and share it with someone just starting out

in business central development.

Join us next time where we'll add another piece of the puzzle.

I'm Mirko Peters, and this has been another episode

of Microsoft Knowledge Nuggets on M365 FM.