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.