Business Central customization built as clean extensions

When Business Central customization is the right answer

Standard Business Central covers most finance and supply chain work. A change is worth making when people keep a spreadsheet beside the system. It is also worth it when they type the same value on every order. Or they cannot see the one field they need on the page where they work. Those are signs of a real gap.

It is the wrong answer when the request copies a habit from the old system. So we ask what the step achieves. We show how the standard feature reaches the same result. Only then do we decide whether a change earns its place. Many requests end there, with a setup change and no code.

Personalize, configure, then extend in Business Central

The lightest change is personalization. A user moves, hides or adds fields on their own pages. One level up, an administrator customizes a profile, so a whole role sees the same layout. Neither needs a developer, and both are part of the standard product. You can undo them at any time.

Configuration comes next: workflows, number series, posting groups, report layouts in Word or Excel, and Power Automate flows. We write an extension only when those run out. Even then, we keep it as small as the requirement allows. That order keeps the system close to standard and easy to maintain.

Business Central customization as AL extensions

We write changes to logic or data in AL, as extensions. An extension adds table fields, page controls and event subscribers alongside Microsoft's objects. It does not alter them. That is why updates can arrive without overwriting your work. Microsoft's own partners use the same method for add-on products.

Each change begins as a short written specification that you approve. Then we build it in a sandbox, and you test it with real documents. The code lives in a repository with a version number. After that, we install the extension in production during a quiet window. Nothing reaches live data untested.

What you receive with each Business Central customization

You receive the installed extension and its source code. You also get a test script your users can repeat and a plain description of what the change does and why. If another firm takes over later, they can read it and carry on without guessing. All of it sits with the code, not in an inbox.

We also record every permission the change needs and add it to a permission set. That way, new functions do not quietly fail for users who lack access. Report layouts come as editable files that your own team can adjust. A short walk-through call closes each delivery, so questions get answered early.

Business Central customization pitfalls we steer around

The common mistake is building what an AppSource app already does well. Before we write code for EDI, advanced warehousing or document capture, we compare existing add-ons. A maintained product is usually easier to live with than private code. We say so even when it means less work for us.

Another mistake is piling many small changes into one large extension that nobody fully understands. So we group changes by purpose and avoid copying standard logic. We also test against the next release in a preview sandbox, so an update does not surprise you. Small, named extensions are easier to test, update and retire.

Business Central customization questions

Will customizations break when Microsoft updates Business Central?

Extensions are built to survive updates, because they sit beside the base application. Problems arise when an extension relies on something that Microsoft later changes or removes. So we test each extension against the coming release in a preview sandbox. We then fix anything it flags before the update reaches production. Your users see no change on update day.

What is the difference between personalization and customization?

Personalization is a change that one user makes to their own pages. Profile customization applies a layout to everyone in a role. Customization in the wider sense includes extensions that add fields, logic or pages. The first two need no code at all. So we always try them first, before we plan any development.

Can you take over customizations another partner wrote?

Yes, provided you have the source code or can get it. We read the extensions and note what each one does. Then we check them against the current release and maintain them from there. If the source is missing, we explain your options. One of them may be to rebuild the extension from scratch. We tell you which is simpler.

Do we own the code you write for us?

Code written for your company comes with its source. The agreement sets out the ownership terms before work starts. We also recommend that you keep a copy in a repository that your company controls, whoever maintains it. That way, you can always move to another partner without losing your Business Central customization.

How do you decide between an add-on and custom code?

We compare the requirement with existing add-ons first. If a maintained product covers most of the need, it is usually the safer route. Custom code makes sense when the requirement is specific to your business. It also makes sense when it is small enough that an add-on would be excessive. We explain our reasoning in writing.

Services close to customization

Customization rarely stands alone. It usually follows an implementation, connects to another system, or grows into a larger development project. The pages below cover the work around it. Read them to see where Business Central customization fits in your plan. Then we can talk through the changes you have in mind and choose the lightest way to make each one. For the product detail, see Personalize your workspace in Business Central.