Dynamics 365 Business Central AL Development

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.