Mohana's D365 Business Central & NAV Blog

Data query tools in the Business Central MCP server: a hands-on test guide

noreply@blogger.com (Mohana) — Wed, 07 Oct 2026 16:02:47 +0000

Data Query Tools (Preview) is a server feature on the Business Central MCP server. Switch it on and an agent gets four system tools: it can search your tables, read their fields and relations, write an AL query, have Business Central compile it, and run it.

What makes it useful is what it removes. Until now an agent could only read what an admin had published as an API page or API query, so anything else meant a development request and a deployment. With the data query tools, an agent can answer a question nobody built an object for, which describes most ad hoc analysis. The boundaries become the permissions the signed-in user already has and what an AL query can express. It is read-only, so nothing can be created, changed or deleted through it.

This guide takes you from nothing to a working.

Before you start

A Business Central online sandbox on a version that has the Data Query Tools server feature. It shipped as a preview in 2026 release wave 2.
The MCP - ADMIN permission set, or equivalent, to create MCP configurations.
Visual Studio Code with the GitHub Copilot extension.
Your Microsoft Entra tenant ID, environment name, and company name.

Step 1: create an MCP server configuration

1. In Business Central, search for and open Model Context Protocol (MCP) Server Configurations. The direct page is 8351.

2. Select New.

3. Set Name to something you will recognise in telemetry later. DataQueryTest works, and you will see that exact string in the configurationName dimension in step 9.

4. Set Description to whatever you like.

Leave Unblock Edit Tools off. You are testing read-only analysis, and there is no reason to hand write access to an agent while you do it.

Step 2: turn on the data query tools

1. Find the Server Features section on the configuration.

2. Enable Data Query Tools (Preview).

3. Look at the system tools box next to it. It lists the tools this feature unlocks. If you enable more than one server feature, the box shows the combined set.

You should see four tools appear:

Tool	What it does
bc_data_find_tables	Finds tables by name or semantic similarity, returns table IDs and names
bc_data_get_table_schema	Returns the fields on a table
bc_data_get_table_relations	Returns incoming or outgoing relations for a table
bc_data_query	Compiles and validates an AL query. Returns schema only unless returnData is true

That is the whole configuration for this test. You do not need to add a single API page. That is the point of the feature.

Turn Active on.

Step 3: copy the connection string

1. With the configuration open, select Advanced then Connection String.

2. Copy the JSON, or select Download to save it as a text file.

It looks like this:

"businesscentral": {

"url": "https://mcp.businesscentral.dynamics.com",

"type": "http",

"headers": {

"TenantId": "aaaabbbb-0000-cccc-1111-dddd2222eeee",

"EnvironmentName": "Sandbox",

"Company": "CRONUS USA, Inc.",

"ConfigurationName": "DataQueryTest"

}

Step 4: add the server to VS Code

1. Open VS Code on a folder you can keep. You will be saving .al files here later.

2. Create .vscode/mcp.json if it does not exist.

3. Paste the connection string inside the servers element:

{

"servers": {

"businesscentral": {

"url": "https://mcp.businesscentral.dynamics.com",

"type": "http",

"headers": {

"TenantId": "aaaabbbb-0000-cccc-1111-dddd2222eeee",

"EnvironmentName": "Sandbox",

"Company": "CRONUS USA, Inc.",

"ConfigurationName": "DataQueryTest"

}

4. Save. A small toolbar appears above the server entry in the file. Select Start.

5. Sign in when prompted. Authentication is OAuth 2.0 against Microsoft Entra ID, and VS Code uses a preregistered application, so there is nothing to register yourself.

6. The toolbar text changes to Running.

If you are testing from Claude, ChatGPT, or GitHub Copilot CLI instead, you point at the same URL but you have to register your own Entra application first. The Learn article on non-Microsoft hosts covers that.

What a healthy start looks like

Open the Output panel and pick the channel for your MCP server. A good run reads like this:

[info] Starting server businesscentral

[info] Connection state: Running

[info] Discovered 4 tools

The line that actually matters is the last one. Discovered 4 tools means the data query tools came through.

Step 5: confirm the four tools are really there

This is the step people skip, and then they spend twenty minutes wondering why the agent keeps reaching for an API tool.

Open GitHub Copilot Chat in Agent mode with Ctrl+Shift+I.
Type # in the chat input. That lists every available tool by name, so typing #bc_data filters straight to the four you care about.

The mcp.json code lens is the quickest sanity check of all. Once the server is running, it shows the tool count above the server entry, which is where the Discovered 4 tools figure from step 4 comes from.

Step 6: smoke test, one tool at a time

Run these three prompts before anything ambitious. Each one is designed to force a single tool, so when something breaks you know exactly what broke.

Prompt 1, discovery:

Using only the Business Central data tools, find tables related to item ledger entries. List the table IDs and names you get back. Do not write a query yet.

Expect a call to bc_data_find_tables and a list including table 32, Item Ledger Entry. If you get an apology about not having access to Business Central, the server is not running or the tools are not available.

Prompt 2, schema:

Get the schema for the Value Entry table and show me every field whose name contains "Amount".

Expect bc_data_get_table_schema and a field list including Sales Amount (Actual) and Cost Amount (Actual). This also tells you whether the tool returns data types, which the model needs, because aggregates other than Count only work on Decimal, Integer, BigInteger or Duration fields.

Prompt 3, compile without running:

Write an AL query that returns the No. and Name of the Customer table, compile it with the data query tool, but do not return any rows.

Expect bc_data_query with returnData absent or false, and a schema back rather than rows. This proves the compile path works in isolation, which is the single most useful thing to know before you start debugging a complicated query.

If all three pass, the plumbing is good.

Now go break it

That is the setup done. Six steps, one configuration, no API pages, and an agent that can read your Business Central data by writing AL on the fly.

Composite Layouts in Business Central 29.0: Brand One Report End to End

noreply@blogger.com (Mohana) — Mon, 05 Oct 2026 15:20:52 +0000

Business Central 29.0 lets you stop baking branding into every Word layout. Instead of one file carrying structure, letterhead and typography all at once, you build three separate pieces and Business Central merges them when the report runs.

This walkthrough takes one report from plain to fully branded, then sets it as the default so you never repeat the work.

The nine steps: build the header/footer in Word → register it → approve it → create the theme → get a Body layout → assign both parts → run it → set defaults → do the same in AL.

Before you start: a 29.0 environment, Word on your machine, and the Cronus logo file.

What we are building

We will brand the Standard Sales - Invoice report for a company called Contoso. By the end you will have:

• A header/footer part carrying the Contoso letterhead and a footer with the company registration line

• A theme part carrying the Contoso fonts and colors

• A body layout holding only the invoice structure

• Both parts assigned, first to one layout, then as a company-wide default

what you build · 3 parts, merged at render

Two pages do all the work. Report Layouts holds layouts with subtype Default and Body. Manage themes and header-footer layouts holds the ones with subtype HeaderFooter and Theme. A layout appears on exactly one of them, decided by its subtype.

Step 1. Build the header and footer in Word

Start with a blank Word document. This file will carry nothing but page furniture, so do not add any invoice content to it.

Go to Insert > Header, pick a style, and drop in the Cronus logo. Then Insert > Footer for the address.

Save it as Contoso-External-HF.docx. Plain .docx, not a template.

Step 2. Register the header/footer part in Business Central

Press Alt+Q, type Manage themes and header-footer layouts, and open the page. This page is empty of your own parts on a fresh environment, though Microsoft's shipped designs are already listed.

Choose New header/footer. Enter a Name and Description, then OK.

Select the Contoso-External-HF.docx file you saved. The part is now registered.

Step 3. Approve the part before you try to use it

This is the step that catches everyone. A freshly created part cannot be assigned to anything yet. Try it and you get:

The part Contoso external letterhead is not approved. Only approved themes and header/footer parts can be assigned. Approve it in Report themes and header-footer setup first.

Open Report themes and header-footer setup and click action Set as approved. Then go back.

It is worth understanding why this gate exists rather than clicking through it. These parts are shared. One of them can end up on every outgoing document in the company, so the approval step is what stops a half-finished letterhead from reaching a customer. In a real rollout, treat approval as the point where someone who owns the brand signs off, not as a checkbox the developer ticks.

Step 4. Create the theme part

Same page, different action: New theme.

The important difference is the file type. A theme has to be a Word template, a .dotx file, not a .docx. That is the t in dotx doing its job. A theme carries fonts and a color palette rather than content, which is exactly what a Word template is for. Try to upload a .docx here and it will not take.

So in Word: set up your fonts and colors on the Design tab, then Save As and pick Word Template (*.dotx). Name it Contoso-Brand.dotx and register it as a new theme.

Approve it, same as step 3.

If you want to see what good looks like before building your own, open one of the shipped themes first. Microsoft ships three: Calm, Playful, and Standard, alongside the Default. Calm is muted and green, Playful adds color and gradients. Export one, look at how it is put together, then build yours from that starting point rather than from blank.

Step 5. Get yourself a Body layout

Here is the part that trips people up on day one, so read it before you start clicking.

A theme and a header/footer can only be assigned to a layout whose subtype is Body. Not Default. The difference matters because a Default layout is a complete document that already owns its own header, footer and styling, so there is nothing for the merge to add. A Body layout is deliberately incomplete and expects the other two parts to be merged in at render time.

On the Report Layouts page you will see the new Subtype column. Filter it and check what you actually have. Two things you will hit:

• Select an RDLC layout and the composite actions are greyed out. This feature is Word only.

• Select a Default layout and you get an error telling you the layout cannot carry a theme or header/footer.

If the report you want has no Body layout, the quickest route is to export the existing standard layout, then import it back as a new layout with the subtype set to Body. Open it in Word first and strip out the header, the footer and the hard-coded styling, because those are now the job of your two parts. What should be left is the invoice structure and nothing else.

Run it at this point, before assigning anything. You should get a very plain document with no letterhead and no branding. That is correct, and it is a useful checkpoint: if it still looks branded, you have not stripped the layout properly and you will get a doubled-up header later.

Step 6. Assign the theme and header/footer

Select your body layout on Report Layouts, open the Composite Layout menu, and choose Set report theme and header-footer.

Pick Contoso external letterhead as the header/footer part and Contoso Brand as the theme part. If either one is missing from the dropdown, it is not approved yet. Go back to step 3.

Step 7. Run it

Run the Sales Invoice and pick your body layout. The PDF now comes out with the Contoso letterhead on page one, the registration footer on every page, and your fonts and colors throughout. The body layout file itself has not changed since step 5. The merge happened at render time.

Step 8. Set defaults so you stop doing step 6

Assigning parts layout by layout works, but it does not scale past a handful. The defaults page is where this becomes genuinely useful.

Open Report defaults for themes and header-footer setup. You can set a default theme and header/footer at four levels, and the most specific one wins.

defaults cascade · 4 levels, most specific wins

Worked through with our example:

1. Global. Set Contoso Brand and the external letterhead here. Every document report in every company now uses them.

2. Company. Contoso Denmark needs a different registration footer. Add a company-level row for it, pointing at a Danish header/footer part. Denmark overrides global; everything else still follows global.

3. Report. Credit memos need a plainer treatment than invoices. Set a report-level row on the credit memo report.

4. Layout. One specific body layout needs something unusual. Set it there, exactly as you did in step 6.

The multi-company case is where this earns its keep. Set Danish branding once on the Danish company and every document report in that company follows, with no per-report work at all. Add a Swedish company next year and it is one row, not a layout migration.

Step 9. The same thing in AL

Everything above has a code equivalent. Three properties do it, all documented in the AL Language extension changelog: Subtype on the layout, plus HeaderFooterPart and ThemePart on a body layout.

report 50100 "Contoso Sales Invoice"
{
    Caption = 'Contoso Sales Invoice';
    DefaultRenderingLayout = ContosoInvoiceBody;

    dataset
    {
        // data items here
    }

    rendering
    {
        layout(ContosoInvoiceBody)
        {
            Type = Word;
            Subtype = Body;
            LayoutFile = './Layouts/ContosoInvoice-Body.docx';
            Caption = 'Contoso sales invoice';
            Summary = 'Invoice structure only. Theme and header/footer merge at render time.';
            HeaderFooterPart = ContosoExternalHF;
            ThemePart = ContosoBrandTheme;
        }

        layout(ContosoExternalHF)
        {
            Type = Word;
            Subtype = HeaderFooter;
            LayoutFile = './Layouts/Contoso-External-HF.docx';
            Caption = 'Contoso external letterhead';
            Summary = 'Logo, address block, registration footer.';
        }

        layout(ContosoBrandTheme)
        {
            Type = Word;
            Subtype = Theme;
            LayoutFile = './Layouts/Contoso-Brand.dotx';
            Caption = 'Contoso brand theme';
            Summary = 'Corporate fonts and color palette.';
        }
    }
}

Note the file extensions in LayoutFile, because the compiler will hold you to them. Theme points at .dotx. Body and HeaderFooter point at .docx.

If you are building a branding extension rather than a report, you can ship nothing but parts. A report extension that adds only Theme and HeaderFooter layouts puts them into the shared pool for administrators to assign from the setup page:

reportextension 50101 ContosoBrandParts extends "Standard Sales - Invoice"
{
    rendering
    {
        layout(ContosoInternalHF)
        {
            Type = Word;
            Subtype = HeaderFooter;
            LayoutFile = './Layouts/Contoso-Internal-HF.docx';
            Caption = 'Contoso internal header/footer';
            Summary = 'Single rule line. For internal print and PDF.';
        }

        layout(ContosoCalmTheme)
        {
            Type = Word;
            Subtype = Theme;
            LayoutFile = './Layouts/Contoso-Calm.dotx';
            Caption = 'Contoso calm theme';
        }
    }
}

One 29.0 change makes reusable header/footer parts work far better than they otherwise would: Word layouts now include a company information dataitem shared across every report dataset. A shared letterhead needs the company address and registration number, and it can no longer assume each report declared them. That dataitem is why a single header/footer part can sit on fifty different reports and still print the right company details.

So the migration looks like this: build the body layout and parts alongside the old layout, assign and test, then retire the old layout rather than deleting it. If something is wrong, flip the status back. Nobody loses a document in the meantime.

Record.IsDirty in Business Central 29: a worked example

noreply@blogger.com (Mohana) — Fri, 02 Oct 2026 06:07:43 +0000

Business Central 29 adds IsDirty to the Record API. It lets your AL code ask a record whether anything has changed since it was loaded, so you can skip writes that aren't needed and stop tracking change state by hand. In this post I'll show how it behaves on a Customer Card, and where it fits in real code.

What IsDirty does

Record.IsDirty() tells you whether a record instance has changed since it was loaded. It returns true when the in-memory values differ from what came back from the database, and false when they still match.

procedure IsDirty(): Boolean

That gives you a clean way to decide whether a record needs validating, saving, or a prompt to the user, without keeping track of the state yourself.

If you've worked with RecordRef, this will look familiar. RecordRef.IsDirty() has been around since runtime 5.0. Version 29 brings the same capability to the Record data type, so you ask the question directly on the record you're already working with.

Seeing it on a Customer Card

The quickest way to see what IsDirty reports is a page action. Add this page extension to a sandbox, open any customer, and run the action.

pageextension 50100 "Customer Card IsDirty Demo" extends "Customer Card"

{

actions

{

addlast(Processing)

{

action(IsDirtyDemo)

{

ApplicationArea = All;

Caption = 'IsDirty Demo';

ToolTip = 'Shows how Record.IsDirty reports changes on this customer.';

trigger OnAction()

var

Customer: Record Customer;

DirtyMsg: Label 'IsDirty after %1: %2', Comment = '%1 = step name, %2 = Yes or No';

begin

Customer.Get(Rec."No.");

Message(DirtyMsg, 'Get', Customer.IsDirty());

Customer.Name := 'IsDirty test';

Message(DirtyMsg, 'changing Name in memory', Customer.IsDirty());

end;

}

Set runtime to 18.0 or later in app.json before you build it.

The first message shows No. The record has just been loaded and nothing has changed.

The second message shows Yes. The Name in memory no longer matches what's stored in the database.

Version and availability

IsDirty ships with Business Central 2026 release wave 2, version 29.

The runtime floor is 18.0. Compiling against runtime 17.0 produces diagnostic AL0666, stating that IsDirty is not available in that runtime version and that 18.0 or greater is required. Set runtime to 18.0 in app.json before you use it.

Business Central 2026 Release Wave 2 (v29.0) Is Generally Available

noreply@blogger.com (Mohana) — Thu, 01 Oct 2026 15:47:44 +0000

Version 29.0 of Business Central is now generally available. If you create a new online environment today, 29.0 is what you get by default.

Spinning up a 29.0 sandbox

The quickest way to see this for yourself is the admin center. Go to Environments, choose New, and look at the Version dropdown. 29.0 is now sitting there as a selectable option rather than a preview build.

If you have been testing on a preview sandbox, read this

The preview sandboxes you created in September are on borrowed time. Microsoft deletes them automatically about 30 days after GA, which puts the cutoff somewhere in early November 2026. You also cannot update a preview environment to a different version, so there is no path from a preview sandbox to a supported one.

If you have test data, custom extensions, or configuration sitting in one of those, move it now. Export what you need and recreate the environment on the GA build of 29.0.

Links worth keeping

What	Where
What's new and changed in 29.0	Microsoft Learn
AI at Work Roadmap, filtered to Business Central	microsoft.com
Release Communications MCP Server setup	Microsoft Learn
What's new videos	aka.ms/BCLE
Partner PowerPoint deck for customer conversations	aka.ms/BCDeck
Office Hours calls	aka.ms/BCOfficeHours

NAV to Business Central: What Actually Moves, and What Needs to Change?

noreply@blogger.com (Mohana) — Wed, 16 Sep 2026 09:58:16 +0000

In Part 1 I argued that NAV, GP and SL customers should start planning now instead of waiting for a lifecycle date to force the decision.

The next question is always more practical:

"What actually happens when we move from Dynamics NAV to Business Central?"

Most people picture one of two extremes. Either it's a database upgrade, or it's a rebuild from scratch. Neither is right, and the space between them is where most project surprises live.

So let me start with the thing that clears up the most confusion.

It isn't one move. It's an upgrade, then a migration

There is no supported route that takes a NAV database straight into Business Central online. The cloud migration tool moves data from a Business Central on-premises database into an online tenant. NAV isn't a valid source for it.

That means every NAV customer is doing two projects that get discussed as one:

1. An upgrade, from your NAV version to a Business Central on-premises version the cloud migration tool supports. Usually more than one hop.

2. A cloud migration, from that on-premises database into Business Central online.

Microsoft's documented routes look like this:

Your current version	Route to Business Central online
NAV 2015 through 2018, and BC 13	BC 14, then BC 25, then cloud migration to online
NAV 2013 / 2013 R2	NAV 2018, then BC 14, then BC 25, then online
NAV 2009 SP1 / 2009 R2	NAV 2013 or 2015, then NAV 2018, then BC 14, then BC 25, then online

There are two mandatory waypoints on that route, and both catch people out.

Version 14 (the 2019 Spring release) is the last version that still understands the old development model, which is exactly why every path passes through it. Worth knowing: its mainstream support ended in October 2023, minor updates stopped, and new customers can't run it in production. It exists purely as a stepping stone.

Version 25 (2024 release wave 2) became mandatory more recently. Starting with 2025 release wave 1 (v26), direct upgrade from version 14 to the latest release stopped being supported, and the path now runs through v25. So you can't go from 14 straight to a current release. If your target is Business Central on-premises rather than online, add one more hop from v25 to the current version on top of that.

The practical consequence: your NAV version doesn't just affect effort, it determines how many technical upgrades you're doing before the migration even begins. A NAV 2018 customer is doing two, to 14 and then 25. A NAV 2009 customer is doing four. That's why "which version are we on" is the first question I ask, and why the answer moves the timeline more than the customization count does.

One caveat on the numbers above. Waypoints shift with release waves, and the v25 requirement itself only appeared with v26. Check the current supported upgrade paths on Microsoft Learn before you build a plan around any specific version.

What "moves" actually means

The cloud migration itself is data replication. You install an Integration Runtime next to your on-premises database, connect it to the online tenant, select companies, and run replication through Azure Data Factory. Initial load, then deltas, then a data upgrade on the online side, then you complete the migration so the online environment becomes the primary system.

Two things follow from that, and the second one catches people out.

Code does not replicate. Tables and fields exist in the cloud only because an extension in that tenant declares them. There is no mechanism that carries application objects across.

And your data is coupled to that code. Data from tables with code customizations can't be carried forward unless those customizations are handled by extensions installed both on-premises and online.

That second point deserves a second read. It isn't only "your C/AL has to be rewritten." Your data in customized tables has nowhere to land until the matching extension exists on both sides of the replication. A custom field on the Item table, or a custom table holding ten years of quality inspection records, stays behind until the AL extension defining it is installed in both environments.

If there's one sentence I'd want a NAV customer to absorb before anyone estimates anything, it's that one.

The real decision: full migration or reimplementation

Microsoft documents two paths, and choosing between them shapes the whole project.

Full migration. All data and customizations. Requires converting C/AL to AL extensions and upgrading through to a current version. This is what people usually mean when they say "migration."

Reimplementation. Essential business data only: master data, balances, a subset of posted historical entries, and setup. It doesn't require converting your extensions, and it doesn't require upgrading beyond version 14. There's a dedicated Business Central 14 reimplementation tool for it.

Both paths still require reaching version 14 first. That part isn't optional.

Both approaches are valid. The right choice depends on the customer's data, customizations, integrations and business requirements, and I've seen both work well.

Full migration tends to fit when:

Historical transactions are operationally necessary, for example serial and lot traceability, long-running service contracts, or warranty claims against old shipments.
Customizations are still central to how the business runs, so they need to exist in AL regardless.
Audit or statutory obligations depend on detailed history being available inside the ERP.
The third-party solutions in use have Business Central online equivalents.

Reimplementation tends to fit when:

History is needed for reference and can reasonably live in a reporting or archive system.
A meaningful share of customizations turn out to be workarounds, unused, or now standard functionality.
The business wants to standardize processes rather than carry existing ones forward.
Some customized tables have no clear business owner willing to fund converting them.

If the choice isn't obvious, estimate both. The comparison usually tells you more about the project than either estimate does on its own.

What I'd avoid is treating this as a technical footnote. It's a business decision about what the company actually needs in the new system, and it belongs in the first few conversations, not in a design document six months later.

What usually needs technical work

C/AL customizations

They don't run in Business Central. Not online, and not in modern on-premises versions either, since C/AL was removed from the product entirely. Everything has to become AL extensions, or has to be dropped.

That doesn't mean rewriting line for line. Some of what you customized in 2012 is standard functionality now. Some was a workaround for a limitation that no longer exists. Some nobody uses. I'll cover how I assess this in Part 3.

Reports

Many NAV environments carry years of customized reports. Before converting any of them, I answer two questions: is this report still being opened, and does Business Central already provide an equivalent? Report usage data from your existing system is more reliable here than asking users, who tend to say yes to everything.

Integrations

Integrations deserve their own workstream. NAV environments connect to banking, CRM, payroll, warehouse systems, shipping providers, tax portals and in-house applications. Anything that authenticated against an on-premises service, used a fixed internal endpoint, or relied on file drops on a shared folder needs rework for a cloud tenant.

I've seen a project where the data migration completed cleanly and the numbers reconciled, and users still couldn't work on day one, because an integration nobody had listed as in scope was the thing that actually fed daily transactions into the system.

Third-party solutions

This is the item most likely to set your timeline, and it's the one people discuss last. If an add-on isn't available as an app for Business Central online, you either replace it, rebuild the functionality, or reconsider the path. Check availability early, because the answer can change the whole plan.

Permissions and licensing

NAV permission sets don't carry across cleanly, and licensing works differently. Essentials and Premium are licensed per user, and license type assignment affects what people can do. Teams users with certain Microsoft 365 plans can get read-only access to Business Central data at no extra cost, provided the organization holds at least one Business Central license. This is worth modelling properly rather than discovering during user acceptance testing.

Job queues and scheduled processing

These don't arrive as working configuration. They get set up again, and the behavior differs from what your NAS-based processing did. Inventory them, because they're easy to forget and very visible when they're missing.

Localizations

Country and region specific functionality arrives in Business Central online through localization apps. Verify the localization you need is available for your country, and confirm that any locally customized tax, regulatory or statutory reporting logic has been converted into AL extensions that work with that localization. In my experience this is where India, and other markets with heavy statutory requirements, needs more attention than a generic project plan allows for.

Before you estimate anything

Part 1 listed the questions I'd ask during an assessment, so I won't repeat them here. But this stage adds three that are specific to the route:

1. Which NAV version exactly, including build? This sets the number of upgrade hops, and each hop is a project with its own testing cycle.

2. Does every customized table have an owner willing to fund its extension? If not, that data isn't moving, and the business needs to know now.

3. Which third-party solutions have a Business Central online equivalent? Check before committing to a date.

Answer these and the migration stops being an open-ended question and becomes a scope you can price.

The bottom line

Moving from NAV to Business Central isn't a single event, and it isn't a choice between "everything moves" and "everything gets rebuilt."

It's an upgrade path to version 14 and beyond, followed by a data replication into the cloud, with one hard rule sitting underneath it: your data travels only as far as your code does.

Once a customer understands that, the interesting conversation starts. Not "can we migrate," but "what do we actually want to take with us."

How I Recreated the Extension Upload Experience in Business Central

noreply@blogger.com (Mohana) — Mon, 14 Sep 2026 11:33:10 +0000

Microsoft has deprecated the in-product upload on the Extension Management page and the Automation API extensionUpload endpoint. Both are scheduled for removal in 2027 release wave 1 (version 30). Extension Management is expected to survive only as a read-only list.

https://mohana-dynamicsnav.blogspot.com/2026/09/managing-apps-in-business-central-admin.html

The supported replacement is the Business Central admin center API so I built an app that calls it from AL.

PTE Extension Management gives you a page that looks and behaves like the one you already use:

Installed Extensions (Admin Center) live list of what is installed, with available update versions and scope.
Upload Extension — pick a .app, choose when to deploy (current version, update window, next minor, next major), set the schema sync mode, and accept the publisher terms.
Uninstall — with an optional, confirmed delete of the extension's data.
Installation Status, Scheduled Installs, and per-extension Operations so you can see what the API actually did.
Deployment Log — every attempt, with user, environment, HTTP status, operation ID, and the raw response body.

Setup is a one-time job:

Step 1. Create the app registration

Go to the Azure portal, then Microsoft Entra ID > App registrations > New registration.

Step 2. Copy the Application (client) ID - you will paste this into Business Central

Step 3. Create a client secret

Go to Certificates & secrets > Client secrets > New client secret.

Step 4. Add API permissions

Go to API permissions > Add a permission > APIs my organization uses, and search for Dynamics 365 Business Central.

Choose Application permissions, and select the permission that grants admin center API access for your tenant.

Then select Grant admin consent for [tenant] and confirm. The Status column must show a green tick for every permission before you continue.

Step 5. Register the app in Business Central

In Business Central, use Tell Me to open Microsoft Entra Applications. Select New.

Client ID: paste the Application (client) ID from Step 2

Step 6. Assign Exten. Mgt. - Admin

On the same card, in the User Permission Sets subpage, add a line and select Exten. Mgt. - Admin.

State: set to Enabled

Step 7. Grant consent

Select Grant Consent on the Entra Applications page and complete the prompt with an account that can consent on behalf of the organization.

Step 8. Open the setup page

Open MPA Deploy Setup.

Step 9. Enter the credentials

In the Entra Application group:

Client ID: paste the Application (client) ID
Client Secret: paste the secret value from Step 3

Step 10. Test the connection

Select Test Connection.

The app requests a token, calls the installed apps endpoint on the target environment, and reports how many extensions came back. A number means authentication, permissions, and environment routing are all correct.

Step 11. Assign the permission set to users

Assign MPA Deploy Admin to the people who should be able to deploy. It is a standalone permission set and is not included in any Microsoft permission set, so nobody gets it by accident.

Step 12. Deploy a package

Open Installed Extensions (Admin Center) and Upload Extensions action.
Select Select Package, choose an .app file, decide whether to install now or wait for the update window, and select Deploy.

Step 13. Check the Installation Status

Open Installation Status action. Track the status to watch the install complete.

The source is on GitHub. Try it in a sandbox, tell me where it breaks, and open an issue if something is missing or wrong. Feature suggestions are just as welcome as bug reports.

https://github.com/pmohanakrishna/PTE-Extension-Management

Pinned Comment Lines for Microsoft Dynamics 365 Business Central

noreply@blogger.com (Mohana) — Sat, 12 Sep 2026 05:48:35 +0000

An extension that makes important notes on customers, vendors, and items visible at the moment they matter, instead of hidden two clicks away.

The problem

Business Central already lets you record comments against a customer, a vendor, or an item. Someone careful writes down "always confirm the PO number before shipping" or "this customer disputes every invoice, copy the account manager", and the note is saved correctly.

Then nobody reads it.

Not because the note is wrong, but because of where it lives. Comments sit behind Customer > Comments, off the main card, on a page most users never open. The person picking and shipping the order has no reason to look there, and no indication that anything is waiting for them. The information is in the system; it simply isn't where the decision gets made.

What this extension does

It adds a single Pinned tick to the comment sheet you already use.

A pinned comment raises an on-screen notification whenever that customer, vendor, or item comes into play when the card is opened, when a sales or purchase document for them is opened, and when a pinned item is entered on a document line. The note travels to the point of work on its own.

Nothing about the existing comment functionality changes. This is not a replacement notes system: there is no new table, no separate editor, and no data to migrate. An existing comment becomes a pinned comment with one tick, and un-ticking it returns everything to normal.

Pinning a comment

1. Open a customer, vendor, or item, and click Comments action.

2. Write the comment exactly as you do today.

3. Tick Pinned.

Three fields are added to the comment sheet:

Field	Purpose
Pinned	Marks the line to be raised as a notification.
Pin Until	Optional last date the note should appear. Leave blank to pin it indefinitely.
Pin Severity	Information for ordinary notes, Warning for notes that must not be missed.

Pinned lines are highlighted on the comment sheet itself, so it is obvious at a glance which notes are active, bold for Information, red for Warning.

Where the notification appears

Record	When it appears
Customer card	Every time the card is opened
Vendor card	Every time the card is opened
Item card	Every time the card is opened
Sales quote, order, invoice, credit memo, return order, blanket order	When the document is opened, and when the customer is entered
Purchase quote, order, invoice, credit memo, return order, blanket order	When the document is opened, and when the vendor is entered
Sales and purchase lines	When a pinned item is entered on the line

The notification reappears every time, not just the first time. If a user glances away or dismisses it, it will be there again the next time they open the record. A warning that shows once and then goes quiet is worse than no warning, because people assume they are covered.

What the notification says

All pinned comments for one record are combined into a single notification rather than one per line. Each pinned comment line appears as its own note, in comment sheet order, separated by a vertical bar:

Pinned comments (3): Always confirm the PO number before shipping | Delivery bookings need 48 hours notice | Invoices must quote the contract number

Longer messages are shortened to keep the banner readable, and blank lines are ignored. If any of the pinned lines is marked Warning, the whole notification is presented as a warning.

Every notification carries a Show comments action that opens the comment sheet filtered to that record, so the full text is always one click away.

Notes that expire on their own

Pin Until exists so temporary notes do not become permanent clutter. Set it to the date a note stops being relevant, the end of a promotion, the date a dispute is expected to close, the last day of a delivery embargo.

Once that date passes, the note simply stops appearing. Nothing needs to be tidied up, no error is raised, and the comment itself stays on the sheet as a record of what happened. Clearing the date or setting a later one brings it back.

Users stay in control

The notification is registered with Business Central's standard notification framework. Any user who does not want it can search for My Notifications and clear Pinned comment lines, alongside every other notification the system offers.

There is no separate setup page to find or learn, and no administrator involvement required. The notification is switched on by default.

Safe for automated processes

Notifications are shown only to users working in the client. Batch posting, job queue entries, API calls, and web service integrations are unaffected. A pinned comment never interrupts an automated process or causes it to fail.

No configuration is needed after installation. Existing comments are untouched until someone ticks Pinned.

At a glance


Applies to	Customers, vendors, items
Requires	Business Central 26 or later
Setup	None
New pages	None
Licence	MIT, free to use and modify
Source	https://github.com/pmohanakrishna/pinned-comment-lines

You can't see your stale documents, and that's why they're stale

noreply@blogger.com (Mohana) — Fri, 11 Sep 2026 12:28:34 +0000

Open the sales order list in Business Central and filter by date. Now do the same for quotes. Now for unposted invoices. Three lists, three filters, no way to see them together, and no way to answer the only question that matters in a Monday pipeline meeting: what is stale, and whose is it?

So the documents pile up. Quotes nobody chased. Orders shipped three weeks ago and never invoiced. Invoices sitting unposted since last month because the person who raised them went on leave. Every partner I've worked with has fielded this request, and the usual answer is a manual Excel pull that someone does once, shows in a meeting, and never does again.

I built Unposted Document Aging to replace that Excel pull with a page.

One list, aged into bands

The extension adds a single read-only list that pulls sales quotes, orders and unposted invoices and optionally purchase documents into one view, with the age of each document and the person who owns it.

The important part isn't the list. It's the bands.

A flat list of 400 stale documents gets opened once. An order created yesterday with nothing shipped is not a problem; an order fully shipped three weeks ago and never invoiced is money sitting on the floor. Those two things should not look the same on screen. So every row lands in one of six bands, sorted so the money is at the top:

Band	Rule
Shipped Not Invoiced	Order completely shipped, or with any line showing a shipped quantity
Quote Expired	Quote whose Quote Valid To Date has passed
Invoice Unposted	Unposted invoice older than the invoice threshold
Order Stale	Order past the order threshold with nothing shipped
Quote Stale	Quote past the quote threshold, not yet expired
Other	Fallback

Shipped Not Invoiced and Quote Expired are highlighted in red. Thresholds default to 30 days for quotes, 14 for orders and 7 for unposted invoices, and are configurable per company.

The argument you're going to have about dates

Here's the design decision that determines whether anyone trusts the page: which date defines "old"?

Document Date is what people mean when they say a quote is old. It is also backdated regularly, which is precisely why some people won't trust a report built on it.

Created uses the record's SystemCreatedAt and tells you when the document genuinely appeared in the system. Harder to argue with, less intuitive.

I made it a setup switch and defaulted to Document Date, because that's the one people will argue about in the meeting and they should be able to flip it and see both.

No stored data

The list is a temporary buffer built on demand by a codeunit, with the page bound to it using SourceTableTemporary. Nothing is stored. There's no job queue keeping a table warm, nothing to go stale, no upgrade code, and the numbers always reflect the live document tables. Hit Refresh and it rebuilds.

A query object can't union across Sales Header and Purchase Header, so the buffer was the only sensible route anyway but the absence of stored state turned out to be the best property of the design.

Performance was the thing I worried about most, since building a buffer from scratch on every page open is exactly how you write a slow app. What keeps it honest:

Every threshold is turned into a cutoff date in AL and applied as a SetFilter on the header, so SQL does the filtering. There is no loop over open documents testing ages in code.
One pass per document type, so each gets its own cutoff rather than a lowest-common-denominator filter.
SetLoadFields on both header loops.
Amount Including VAT is a FlowField, so CalcFields runs only on rows that already made it into the buffer never before filtering. There's a Calculate Amounts toggle to turn it off entirely on very large databases.

Amounts are converted to LCY so a mixed-currency list totals meaningfully, with the currency code kept for display. Choosing a document number opens the actual document, whatever type it is, via a stored RecordId.

The part that actually changes behaviour

A page helps the person who opens it. A digest helps everyone else.

The extension can email a daily digest, and the feature worth having is that it's per salesperson. Rows are grouped by salesperson code, each person's address is resolved from their Salesperson/Purchaser record, and each person gets only their own rows. A digest that goes to everyone gets filtered into a folder and ignored. One that says "you have 6 quotes over 30 days old" gets read.

Managers and shared mailboxes can be added as separate recipients, optionally filtered to a subset of salespeople. It sends through the modern email module with its own Email Scenario, so an admin can point it at a dedicated account on the Email Accounts page. One bad address doesn't abort the run, failures are collected and shown on the setup page. There's a button that creates the recurring job queue entry so nobody has to know a codeunit ID.

It's a per-tenant extension targeting BC 26 and later, and it compiles clean under CodeCop and UICop.

Source: https://github.com/pmohanakrishna/Unposted-Document-Aging

If you install it and the bands don't match how your team actually triages work, that's the most useful thing you could tell me.

Managing Apps in the Business Central Admin Center

noreply@blogger.com (Mohana) — Thu, 10 Sep 2026 10:24:29 +0000

A BC environment is really a stack of apps: Base Application, Microsoft first-party apps, ISV apps, and your own per-tenant extensions (PTEs). The Manage Apps page in the admin center is where you keep all of that under control. Here's what it actually lets you do.

Getting there

Environments > select the environment > Apps. Use the dropdown to switch between Global, Per-Tenant Extension, and Dev Extension apps. Click an app name to open App Details for the actions on that specific app.

What you can do, by app type

App type	View	Upload	Install	Update	Uninstall
Global (marketplace)	Yes	No	No	Yes	Yes
Per-Tenant Extension	Yes	Yes	Yes	Yes	Yes
Dev Extension	Yes	No	No	No	Yes

The one to remember: you can't install a new global app from here, only update or uninstall one already on the environment. New global apps come from marketplace.microsoft.com (the site Microsoft used to call AppSource).

Per-tenant extensions

Choose Install Extension from Manage Apps or App Details:

1. Select the .app file: BC figures out if it's new or an update.

2. Pick a Deployment schedule (immediately, next update window, or next minor/major update: new PTEs only get the first two).

3. Pick a Sync Mode. (Add or Force Sync)

4. Confirm, and track progress on the Operations page.

A few rules to keep in mind:

Don't mix this with Extension Management in the client. Scheduled installs from one won't show in the other until they finish.
Extension Management is being phased out as an upload surface. Move PTE deployment to the admin center or the Admin Center API now, since Microsoft has said the client-side upload option is expected to go away in 2027 release wave 1.
You can queue different versions of the same PTE against different schedules, but not two versions against the same schedule.

Uninstalling an app

Test uninstalls in a sandbox copy of production first. You'll find the Uninstall action on Manage Apps or App Details; apps like Base Application that can't be removed show N/A.

Two things to watch:

You can choose to delete the app's data too. If you do, your only way back is a point-in-time restore (28 days), so export the database first if you need a longer safety net.
Dependent apps get uninstalled too, and BC will list them for you to confirm.

Quick checklist

Review Manage Apps on a schedule, not just when something breaks
Use the update window instead of pushing updates mid-day
Set Apps Update Cadence on purpose
Move PTE deployment off Extension Management now
Rehearse uninstalls in sandbox, and export data before any deletion
Always grab the Operation ID on a failed update

Direct transfers from warehouse-enabled locations in Business Central 2026 wave 2

noreply@blogger.com (Mohana) — Wed, 09 Sep 2026 07:22:10 +0000

Direct transfers have always been the shortcut option for moving stock between locations. No in-transit location, no separate ship and receive steps, one posting and you are done. The catch was that the moment your source location had any real warehouse configuration on it, the shortcut stopped feeling like a shortcut.

Update 29.0 (2026 release wave 2) addresses two related things: direct transfers now work properly with outbound warehouse handling at the source location, and the posting method is no longer a single company-wide switch. You can set it per transfer route.

Quick refresher on the two posting methods

A direct transfer skips the in-transit location. What happens behind the scenes depends on which posting method is in play, and the difference matters more than the name suggests.

Direct Transfer posts one Posted Direct Transfer document. Business Central posts the full transfer line quantity. No transfer shipment, no transfer receipt. Per the current documentation, this produces two item ledger entries: transfer from the source location and transfer to the destination location.

Shipment and Receipt posts a transfer shipment and a transfer receipt together, so you end up with both a posted transfer shipment and a posted transfer receipt. Qty. to Ship must equal Qty. to Receive. Per the current documentation, this produces four item ledger entries, routed through a blank location rather than a real in-transit location.

What changed in the setup

Previously, one setting on the Inventory Setup page decided how Business Central posted every direct transfer in the company. If you had a mix of simple store-to-store moves and warehouse-controlled moves, you picked one method and lived with it.

Now there are two levels:

Default Direct Transfer Posting on the Inventory Setup page sets the company-wide default.
Direct Transfer Posting on the Transfer Routes page overrides the default for a specific route.

The transfer order uses the route setting when one exists, and falls back to the Inventory Setup default when it does not. You can also change Direct Transfer Posting on an open transfer order when a one-off needs different treatment.

Outbound warehouse scenarios

This is the part that unlocks the feature for warehouse-enabled sites. How you complete the transfer depends on how the transfer-from location is configured.

Transfer-from location setup	How you complete the transfer
No warehouse requirements	Post from the Transfer Order
Require Pick without Require Shipment	Create and post an Inventory Pick
Require Shipment without Require Pick	Create and post a Warehouse Shipment
Require Pick and Require Shipment	Register the Warehouse Pick, then post the Warehouse Shipment
Bin Mandatory	Enter valid source and destination bins, then post from whichever document the other warehouse settings require
Directed Put-away and Pick at the source	Register the warehouse pick and post the warehouse shipment using the advanced warehouse process

Partial posting is supported when you post from a warehouse shipment under the Shipment and Receipt method. Everywhere else, expect the full line quantity.

Walkthrough

1. Set the company default

Search for Inventory Setup and set Default Direct Transfer Posting. Pick the method that fits the majority of your transfers, because everything without a route-level override inherits this.

2. Override the method on a transfer route

Search for Transfer Routes. For the route you want to treat differently, turn on Direct Transfer and set Direct Transfer Posting.

3. Confirm the source location setup

Open the Location Card for the transfer-from location and check Require Pick, Require Shipment, Bin Mandatory, and Directed Put-away and Pick on the Warehouse FastTab. This combination decides which document you post from later, so note it before you create the order.

4. Create the transfer order

Search for Transfer Orders and create a new one. Fill in Transfer-from Code and Transfer-to Code, then turn on Direct Transfer. Confirm that Direct Transfer Posting picked up the value you expect from the route or the setup default.

5. Add lines and bin codes

Add the item lines. If either location uses bins, fill in Transfer-From Bin Code and Transfer-To Bin Code. A destination that uses bins needs a valid Transfer-To Bin Code or posting will fail.

You can build lines by hand, use Select items for several at once, or pull from Get Bin Content or Get Receipt Lines.

6. Post according to the source setup

No warehouse requirements. Choose Post on the transfer order.

Require Pick only. Choose Create Inventory Put-away/Pick on the released transfer order, open the inventory pick, enter the handled quantities and bins, then post it.

Require Shipment only. Choose Create Warehouse Shipment, open the warehouse shipment, set the quantities, and post. This is the path where partial posting works under Shipment and Receipt.

Require Pick and Require Shipment. Create the warehouse shipment, create the pick from it, register the warehouse pick, then post the warehouse shipment. Registering the pick does not post the transfer, it just makes the quantity available to the shipment.

Directed Put-away and Pick at the source. Same as above, using the standard advanced warehouse flow.

7. Check what got posted

With Direct Transfer, look for the Posted Direct Transfer document. With Shipment and Receipt, look for the posted transfer shipment and the posted transfer receipt.

Then open the item ledger entries for the item and confirm the entry count and the location codes match what you expect.

Limitations to design around

These are stated in the preview documentation and they shape your location setup more than anything else in the feature:

Direct transfer posting does not create inbound warehouse receipts or inventory put-aways.
The transfer-to location cannot use Directed Put-away and Pick.
With Shipment and Receipt, the destination also cannot require warehouse receipt or put-away.
A destination that uses bins requires a valid Transfer-To Bin Code.

Outbound warehouse handling at the source is now in scope.

If the receiving side needs warehouse receipt or directed put-away control, the configuration that supports full warehouse handling on both ends is a transfer order with the Direct Transfer toggle off and an in-transit location.

Business Central 2026 Wave 2: Preview Images Directly in the Web Client

noreply@blogger.com (Mohana) — Tue, 08 Sep 2026 07:07:56 +0000

One of the most practical user experience enhancements in Dynamics 365 Business Central 2026 Release Wave 2 (BC29) is the ability to preview image attachments directly in the web client without downloading them first. This feature brings image files in line with the PDF preview experience introduced in earlier releases and makes working with attachments much more seamless.

What's New?

With BC29, users can open supported image attachments directly within Business Central and view them in a dedicated preview window. There's no need to download the file locally before viewing it.

The viewer experience is similar to the existing PDF and print preview experiences. Users can zoom, navigate, print, and download the image if they want to keep a local copy.

Supported Image Formats

Microsoft has included support for a wide range of image types:

JPEG / JPG
PNG
BMP
SVG
WEBP
ICO
GIF (including animated GIFs)
AVIF (including animated AVIFs)

Safari users also gain support for:

TIFF
TIF

Additional Benefits

Beyond simply opening images, Microsoft has included a couple of nice enhancements:

Animated GIF Support

GIF thumbnails can now be displayed in FactBoxes, including animation support for GIFs up to 48 frames.

Clickable Thumbnails

Image thumbnails and PDF thumbnails become clickable and automatically open the preview window.

These small improvements make document-heavy processes much more user friendly.

Where This Helps

This feature can be useful in many scenarios:

Product images
Item catalogs
Quality inspection photos
Purchase documentation
Service department attachments
Employee receipts and supporting documents
Images generated or uploaded by custom extensions

Instead of downloading multiple files while reviewing records, users can quickly preview them directly inside Business Central.

What About Custom Extensions?

The good news is that Microsoft has made this capability available to extension developers.

For Business Central Online, developers can use:

File.ViewFromStream(...)

Customization Example: Preview an Image Stored in a Custom Table/Field

Suppose you've added a custom Table/field and want users to preview the image directly without downloading it.

Table

table 50100 "Image Test"
{
Caption = 'Image Test';
DataClassification = CustomerContent;

fields
{
field(1; "No."; Code[20])
{
Caption = 'No.';
}

field(10; Description; Text[100])
{
Caption = 'Description';
}

field(20; "File Name"; Text[250])
{
Caption = 'File Name';
}

field(30; "Image Blob"; Blob)
{
Caption = 'Image';
}
}

keys
{
key(PK; "No.")
{
Clustered = true;
}
}
}

page 50100 "Image Test List"
{
Caption = 'Image Test List';
PageType = List;
SourceTable = "Image Test";
UsageCategory = Lists;
ApplicationArea = All;

layout
{
area(Content)
{
repeater(Group)
{
field("No."; Rec."No.")
{
ApplicationArea = All;
}

field(Description; Rec.Description)
{
ApplicationArea = All;
}

field("File Name"; Rec."File Name")
{
ApplicationArea = All;
Editable = false;
}
}
}
}

actions
{
area(Processing)
{
action(UploadImage)
{
Caption = 'Upload Image';
ApplicationArea = All;
Image = Import;
Promoted = true;
PromotedCategory = Process;

trigger OnAction()
var
FileName: Text;
InS: InStream;
OutS: OutStream;
begin
if UploadIntoStream(
'Select Image',
'',
'All Files (*.*)|*.*',
FileName,
InS)
then begin

Clear(Rec."Image Blob");

Rec."Image Blob".CreateOutStream(OutS);
CopyStream(OutS, InS);

Rec."File Name" := FileName;

Rec.Modify(true);

Message('File uploaded: %1', FileName);
end;
end;
}

action(PreviewImage)
{
Caption = 'Preview Image';
ApplicationArea = All;
Image = View;
Promoted = true;
PromotedCategory = Process;

trigger OnAction()
var
InS: InStream;
begin
Rec.CalcFields("Image Blob");

if not Rec."Image Blob".HasValue() then
Error('No image uploaded.');

if Rec."File Name" = '' then
Error('No filename stored.');

Rec."Image Blob".CreateInStream(InS);

File.ViewFromStream(
InS,
Rec."File Name"
);
end;
}
}
}
}

When the user selects Preview Image, the image opens directly inside the BC29 web client without downloading it first.

Why This Matters for Developers

Prior to this feature, many developers had to rely on:

JavaScript control add-ins
SharePoint previews
Temporary downloads
External viewers

With native image preview support now built into the platform, custom solutions become simpler, cleaner, and more consistent with the standard Business Central user experience.

Final Thoughts

The new Preview Images Directly in Web Client feature is one of those enhancements that users will immediately appreciate. It removes unnecessary downloads, provides a familiar viewing experience, and gives developers a standard way to surface image content directly within Business Central.

Combined with support for animated GIFs, clickable thumbnails, and extension development support through File.ViewFromStream, this feature helps make Business Central's document experience more modern and productive.

BC 29 lets a single index span base table and table extension fields

noreply@blogger.com (Mohana) — Mon, 07 Sep 2026 12:50:08 +0000

Business Central 2026 release wave 2 removes a constraint that has shaped how we index extended tables since table extensions existed. In version 29, a key defined in a table extension can contain fields from the base table and fields from the extension at the same time.

That sounds small. In practice it retires one of the most common workarounds in AL development.

The constraint

Microsoft Learn has always been clear about this one. Keys defined in a table extension are secondary keys, because a table extension inherits the primary key of the table it extends. Those secondary keys can include fields from the base table, or fields from the table extension, but a single key cannot include fields from both. Each key has to be all base table fields or all fields from the extension in which it is defined.

Version 18 improved half of the problem. Before that, you could only build keys on the fields your extension added. From version 18 onward you could also add a key on fields that already existed in the base table, which solved a real category of performance issues. The standard example is External Document No. on posted document tables, where the base app key combines it with another field and a direct lookup has no useful index.

What version 18 did not solve is the mixed case. And the mixed case is the one that keeps coming up in real projects.

What the scenario looks like

Say you add a Region Code field to Sales Invoice Header for a customer with a regional reporting requirement. A user wants a list filtered by Sell-to Customer No. and sorted by Region Code, on a table with a few million rows.

Sell-to Customer No. lives in the base table. Region Code lives in your extension. You cannot put them in one key.

Why the constraint existed

This was never a Business Central design decision. It was SQL.

Under the old data model, fields added by table extensions were stored in a companion table, separate from the base table, joined at read time on the primary key. Version 23 improved that by consolidating all extensions to a table into a single companion table, so the server never needed more than one join instead of one per extension. But there were still two physical tables.

SQL Server cannot build a single index across two tables. That is the entire reason a key could not mix base fields with extension fields. The platform was passing the database's answer back to you.

Version 29 changes the storage. According to the release notes, all fields on an AL table are now stored in the same table in the database, and Microsoft attributes the new cross-boundary key capability directly to that change.

Once the fields are physically together, the objection disappears. One table, one index, no problem.

How to verify it yourself

You do not need to wait for the on-premises release to check this, and you do not need database access. The test is a compile.

tableextension 60400 "MPA Sales Invoice Header" extends "Sales Invoice Header"

{

fields

{

field(60400; "Region Code"; Code[20])

{

Caption = 'Region Code';

DataClassification = CustomerContent;

}

keys

{

// "Sell-to Customer No." belongs to the base table, owned by the

// Base Application. "Region Code" is declared right here.

// One key, fields from both sides of the boundary.

key(CustomerRegion; "Sell-to Customer No.", "Region Code") { }

}

Compile it twice, once against symbols from a version 28 sandbox and once against symbols from a version 29 preview sandbox. On version 28 this fails, which is the documented behaviour and what makes the comparison meaningful.

BC28:

The property 'CustomerRegion' can only be set if the specified fields are from the same table.ALAL0423

Key CustomerRegion: "Sell-to Customer No.", "Region Code"

BC29:

What this changes in practice

Some slow lists become fixable without a redesign. Any place a user filters on a standard field and sorts on yours, or the reverse, is now an indexing problem rather than an architecture problem.

Reporting extractions get simpler. Custom analysis views and extracts that combine base and extension fields have had no supported index path. Now they do.

What to be careful about

The constraint going away does not make indexes free.

There is still a limit of 40 keys per table. That limit predates this change and has not moved. Cross-boundary keys are about to look very attractive, and on a popular table with several apps installed, that budget gets consumed faster than anyone plans for.

Every index costs writes. An index that makes one list fast makes every insert and modify on that table slower. On Sales Invoice Header, Item Ledger Entry, or G/L Entry, that is not a theoretical cost. Measure the write path, not only the read you were trying to fix.

Adding an index to a base table means building it during schema sync. On a large production table, that is an upgrade window question rather than a deployment detail. Test the install time on a copy of real data volumes, not on Cronus.

Nobody owns the aggregate. Nothing stops three separate apps each adding a cross-boundary index to Customer. Each decision is defensible on its own, the write cost is shared, and no single publisher sees the whole picture. If you build for multiple ISV environments, this belongs on the list of things you check.

Where this sits right now

The version 29 public preview runs from the first week of September until general availability in the first week of October 2026, and it applies to online sandbox environments only. Not production, not on-premises. Microsoft has said on-premises detail will be added to the documentation when 29.0 goes generally available, and preview sandboxes are deleted around thirty days after that.

So none of this is production guidance yet. But the compile test can be run today, it costs almost nothing, and it answers the question well before anyone gets to look at the SQL. If you maintain apps that extend high volume tables, it is worth knowing now which of your workarounds you are about to be able to delete.

Recently Used Lookup Values Improve Everyday Productivity (BC29)

noreply@blogger.com (Mohana) — Mon, 07 Sep 2026 04:27:35 +0000

One of the practical usability enhancements coming in Dynamics 365 Business Central 2026 Release Wave 2 (BC29) is the new Recently Used in Lookups feature.

While it may seem like a small change, it addresses a common activity that users perform throughout the day: searching and selecting records from lookup fields.

What's New?

Business Central now surfaces recently used records directly within lookup dialogs. When users open a lookup, Business Central can display records they have recently searched for or selected, allowing them to find frequently used values faster without repeatedly performing the same search. The suggestions are personalized to each user based on their usage patterns.

Feature details in update 29.0 public preview for 2026 release wave 2 - Business Central | Microsoft Learn

Where You'll Notice It

This enhancement can be useful anywhere lookup fields are commonly used, including:

Customers
Vendors
Items
Locations
Dimensions
Country/Region Codes
Payment Terms

Users who repeatedly work with the same records can access them more quickly, reducing clicks and data entry time.

Example Scenario

Consider a purchasing agent who frequently creates purchase orders for the same vendors.

Before BC29

1. Open Vendor lookup

2. Search for vendor

3. Select vendor

With BC29

1. Open Vendor lookup

2. Switch to Recent

3. Select vendor

The feature helps reduce repetitive searching and streamlines everyday tasks.

Benefits

Faster Data Entry

Frequently used records are easier to find, reducing repetitive searches.

Personalized Experience

Each user sees recommendations based on their own activity and usage patterns.

Improved Efficiency

Users can spend less time searching and more time processing transactions.

Consistent User Experience

The feature leverages the same underlying intelligence used by other Business Central experiences, providing a more consistent and responsive user interface.

Not Limited to Lookups

During testing, I also noticed that recently used records can be influenced by records accessed through Global Search, not just records selected from lookup dialogs. This helps make the recommendations more relevant by reflecting how users actually navigate and work within Business Central.

A Couple of Wishes for Future Enhancements

While the feature is a welcome addition, there are a couple of improvements that could make it even better:

Include manually entered values in the Recent list. Currently, values entered directly into a field do not appear in Recent. Including successfully validated manual entries would better reflect how many experienced users work within Business Central.
Show Recent records by default. Instead of requiring users to switch to the Recent view each time, an option to open lookups directly on recently used records could further reduce clicks and improve productivity.

Final Thoughts

The new Recently Used in Lookups feature is a simple but valuable enhancement in Business Central 2026 Wave 2. By surfacing recently selected records directly within lookup dialogs, Microsoft is making everyday navigation and data entry faster and more intuitive.

It may not be the biggest feature in BC29, but for users who spend their day creating transactions and maintaining records, the time savings can quickly add up.

Public Preview for Business Central 29.0 (2026 Release Wave 2) Is Here

noreply@blogger.com (Mohana) — Thu, 03 Sep 2026 11:53:27 +0000

The preview environments for Business Central 2026 release wave 2 are now rolling out globally. If you have access to the Business Central admin center, you can spin up a sandbox on version 29.0 today and start looking at what is coming.

Microsoft's announcement and the full details are here: aka.ms/BCMajorUpdates

What this actually is

Twice a year, Business Central gets a major update. Wave 1 lands in April, wave 2 in October. Ahead of each one, Microsoft opens up preview environments so partners and customers can test their own apps, extensions, and integrations against the new version before it becomes the version everyone is running.

That is what just happened. Version 29.0 is the wave 2 release, and the preview build is available now.

This is not a "read the release notes and nod" moment. It is the window where you can find the thing that breaks your customer's environment and get it fixed before it becomes a production incident.

How to get a preview environment

From the Business Central admin center, go to Environments, choose New, and create a Sandbox. In the Version dropdown, pick the 29.0 preview build.

A few things worth knowing before you do:

Create it as a Sandbox, not Production. Preview builds are for testing and nothing else.
Preview environments are temporary. Do not build anything on one that you expect to keep.
Localization matters. If you support multiple countries, test the ones you actually deploy to.

What to test

If you are a partner or an ISV, the list is fairly short and fairly obvious:

Your AL extensions. Recompile against the 29.0 symbols. Deprecations and breaking changes in the base application show up here first, and they show up as compile errors, which is the cheapest possible place to find them.

Your integrations. API pages, OData endpoints, web services, anything talking to Business Central from the outside. These break quietly, which makes them worse than the things that break loudly.

Your customer-specific customizations. The ones nobody has looked at in two years are the ones that will surprise you.

The new features you care about. Check the release plan on Microsoft Learn for what is in wave 2, then go poke at the features that touch your customers' processes. Reading about a feature and using it produce different opinions.

Reporting what you find

If something is broken, report it. This is the part that matters most and gets skipped most.

Bugs and feedback go here: aka.ms/BCPreviewBugs

A good report saves everyone time. Include the version number, the localization, whether it reproduces on a clean environment, and the steps to get there. If you can reproduce it without your own extensions installed, say so, because that immediately tells the engineering team it is theirs and not yours.

Why this is worth your time

The preview window is short. Once the release goes GA and your environments start updating, a problem you could have raised as a preview bug becomes a support ticket with a customer waiting on the other end of it.

The people who find the interesting problems during preview are the ones running real extensions against real data. That is you. Microsoft cannot test every combination of ISV app, custom code, and integration that exists in the field, and it does not pretend to. That is exactly why the preview exists and why the feedback loop is open.

So create a sandbox, recompile your code, and go looking for trouble. Better to find it now.

Dynamics NAV, GP and SL: Why I Think Customers Should Start Planning Now

noreply@blogger.com (Mohana) — Tue, 01 Sep 2026 15:02:04 +0000

If you are still running Dynamics NAV, Dynamics GP, or Dynamics SL, you have probably heard the conversation about moving to Dynamics 365 Business Central.

The question I hear most often is:

"Do we really need to migrate now?"

My answer is usually: you don't necessarily need to migrate tomorrow, but you should start planning now.

I've spent many years working with Dynamics NAV, Business Central, and data migration projects. One thing I've learned is that the actual migration is rarely the hardest part.

The difficult part is deciding what should be migrated in the first place.

Don't Start With the Deadline

When Microsoft announces lifecycle changes, it is natural to look at the dates and start counting backward.

For NAV, Microsoft says the final version was released in 2017 and extended support ends in January 2028. Microsoft also has separate licensing and service-plan changes coming later, including April 30, 2031. These are different milestones, so I would not treat 2028 as a simple "NAV stops working" deadline.

For me, the more important question is not:

"How long can we continue running NAV or GP?"

It is:

"If Business Central is likely to be our next ERP, what should we be doing today to make that move easier?"

That change in thinking can make a big difference.

Your ERP Has Probably Changed a Lot Over the Years

If you've been running NAV or GP for many years, your current system probably doesn't look anything like the original implementation.

There may be:

Customizations
Third-party solutions
Custom reports
Integrations
Historical data
Business-specific processes
Workarounds
Old functionality that nobody remembers why they built

Some of those things may still be critical.

Others may no longer be needed.

And this is where I think migration projects become interesting.

Should we really move all of it?

Probably not.

I've seen situations where people start thinking about migration by creating a list of everything in the existing ERP and asking how to reproduce all of it in Business Central.

I think that's backwards.

I'd rather start with:

What does the business actually need going forward?

Migration Is an Opportunity to Clean Things Up

A migration gives you a rare opportunity to look at the ERP environment with fresh eyes.

For every customization, report, integration, and piece of historical data, I would ask:

Do we still need this?

If the answer is yes:

Does it need to work exactly the same way?

And if the answer is still yes:

Is the existing approach the best way to implement it in Business Central?

That last question is particularly important.

Business Central has a different architecture and extension model from older NAV environments. Microsoft documents supported NAV-to-Business-Central migration paths, but the existing application customizations need to be handled appropriately.

So I wouldn't approach the project as:

"Let's convert everything we have."

I'd approach it as:

"Let's understand what we have, decide what matters, and then determine the best way to build it in Business Central."

Data Is Another Big Question

The same thinking applies to data.

One of the first questions in almost every migration discussion is:

"Can we move all of our historical data?"

Technically, that isn't always the most useful question.

I'd ask:

"What data do our users actually need in Business Central?"

Maybe you need all your history.

Maybe you need master data, open transactions, and opening balances, while older history can remain in another system or reporting environment.

Maybe certain historical transactions are needed for operational reasons, while other data is required only for reporting or audit purposes.

There isn't one answer that works for every customer.

Microsoft's current migration tooling supports different data sets depending on the source system and migration scenario. For example, the GP cloud migration process can migrate setup, master data, transactional data, and historical data, while the specific data to migrate is configurable.

That doesn't mean every customer should migrate everything.

It means there are options.

GP Customers Have Migration Tools, But That Doesn't Mean the Project Is Automatic

For Dynamics GP customers, Microsoft provides built-in cloud migration capabilities for supported GP versions, including GP 2015 and later, subject to the documented prerequisites.

That's good news.

But a migration tool doesn't answer questions such as:

Which customizations should we replace?
Which third-party products do we still need?
Which reports should we rebuild?
Which integrations need to change?
How much historical data should we keep?
How do we validate the financial results?

The technology can help move the data.

The decisions still belong to the project team and the business.

What I Would Do If I Were Starting Today

If I were responsible for a NAV or GP environment today and Business Central was the likely destination, I wouldn't start by scheduling the production migration.

I'd start with an assessment.

I'd want to know:

1. What version are we running?

2. How much customization do we have?

3. What third-party applications are involved?

4. What integrations exist?

5. Which reports are actually being used?

6. How much data do we have?

7. Which historical data do users really need?

8. What business processes depend on custom functionality?

9. What can Business Central handle out of the box?

10. What needs to be redesigned?

Once those questions are answered, the migration strategy becomes much clearer.

Don't Wait Until You Have to Migrate

This is probably my biggest takeaway.

Starting early doesn't mean committing to a go-live date immediately.

It gives you time to:

Understand the existing environment
Clean up data
Review customizations
Evaluate third-party solutions
Test migration options
Identify integration changes
Run mock migrations
Validate the results
Train users
Make better decisions

Microsoft's own migration guidance emphasizes assessment, preparation, test migrations, data replication, validation, and completion as part of the migration process.

That aligns closely with what I've seen in real projects.

The more you understand before the production cutover, the fewer surprises you are likely to have.

My Takeaway

I don't think NAV, GP, or SL customers should look at Microsoft's lifecycle announcements and immediately panic about migration.

But I also don't think waiting until the last possible moment is a good strategy.

If Business Central is likely to be your next ERP, start understanding your current environment now.

Find out what you have.

Find out what you actually use.

Find out what you really need.

Then decide what should move forward.

Because in my experience, a successful ERP migration isn't about moving everything from the old system into the new one.

It's about moving the right things, leaving behind the unnecessary complexity, and taking the opportunity to build something better.

Analysis Mode killed half the Excel exports on your client's shared drive

noreply@blogger.com (Mohana) — Sun, 16 Aug 2026 15:21:23 +0000

Open any client's finance folder and you will find it. Six versions of the same spreadsheet. Customer Aging - Oct.xlsx, Customer Aging - Oct (2).xlsx, Customer Aging FINAL.xlsx, Customer Aging FINAL copy.xlsx. All exported from Business Central.

Nobody built that folder on purpose. It exists because someone once needed to group customer entries by salesperson and month, could not do it on the list page, and hit Open in Excel. Then they needed it again next month.

What actually happens

Hit “Enter analysis mode” and the page changes shape. The normal action bar is replaced by an analysis bar, and the screen splits into two halves.

On the left is the data area, with a summary bar along the bottom and the analysis views bar across the top. On the right are two panes: Columns and Analysis filters.

Nothing you do here touches the underlying data, and nothing you do changes the page for anyone else. That is worth saying to a nervous client before you let them click anything.

Analysis views are the point. The bar at the top starts with one view called Analysis 1. Each view holds its own columns, its own filters, its own pivot arrangement. You might have one for aged balances, one for your top twenty customers, one filtered to overdue items only. They persist between sessions; they are yours alone, and you can rename, duplicate, move, or delete them. Analysis 1 cannot be deleted, only renamed, and Delete All leaves it standing.

The Columns pane has rules. Row Groups accept non-numeric fields only: text, date, time. Values accept only fields that can be summed. Drag something into the wrong area and the client refuses.

One subtlety worth knowing: if you have personalized the page to add a field, it shows up in the Columns pane with its checkbox cleared. It is there; it is just not switched on.

Date hierarchies are generated for you. For each date field in the dataset, Business Central creates three additional fields named after it: Posting Date Year, Posting Date Quarter, and Posting Date Month. Analysing Customer Ledger Entries, you also get the same trio for Document Date, Due Date, and every other date on the page.

The hierarchy is not the field you expand into. It is three fields you stack in Row Groups, and stacking them is what produces the expandable years, quarters, and months with subtotals at each level.

Pivot mode does what you expect. Toggle it on and a Column Labels area appears alongside Row Groups and Values. Rows down the side, labels across the top, sums in the middle. Same model as Excel PivotTable, deliberately.

Note: Columns that only have a few possible values are the best candidates for use in column Values.

It reaches into related tables. “Add columns from” option on the Analysis context menu lets you pull fields in from tables related to the page's source table, and group by them.

And you can export the definition as JSON. Not the data, the analysis itself: columns, filters, arrangement. Which means an analysis view can be packaged into an extension and shipped to a client rather than described in a training document.

Analysis mode needs execute permission on system object 9640, Allow Data Analysis mode, normally granted through the DATA ANALYSIS - EXEC permission set. Most full users have it. Team Member and other limited roles often do not, and permission sets built years ago certainly do not. When a client says the button is not there, check this first. Five minutes, fixes it for a whole department.

Two other reasons can be missing. Developers can switch it off per page with the AnalysisModeEnabled property, so if it is absent on exactly one page, go looking there. And analysis mode is not supported on lists that use indentation, which means Chart of Accounts and the G/L Account List do not have it at all. That is unfortunate, because the Chart of Accounts is the first place a finance person will try. Have the answer ready.

Date hierarchies use the calendar year. Not your client's fiscal year.

The generated Year, Quarter, and Month fields are built on the normal calendar. They do not know about any fiscal calendar defined in Business Central.

If your client's fiscal year starts in April, their Q1 in analysis mode is January to March and their Q1 in every financial report they have ever run is from April to June. No errors. The numbers are correct for the calendar periods they describe. They just do not match the numbers in the meeting.

Also worth knowing: the hierarchy only generates for fields of type Date. Datetime fields do not get one.

Calculated fields are the ones computed on the page rather than read from the database: running totals, percentages, conditional counts. They stop displaying in two situations. When the list goes over 100,000 rows, and whenever you add fields from a related table.

Try it yourself

Ten minutes, and you will have something worth showing a client. This is roughly Microsoft's own aged receivables example with the sharp edges labelled.

1. Open Customer Ledger Entries and choose Enter analysis mode.

2. In the Columns pane, clear every column at once using the checkbox beside the Search field. Start from nothing.

3. Turn on Pivot Mode.

4. Drag Customer Name into Row Groups and Remaining Amount into Values.

5. Drag Due Date Month into Column labels. Twelve columns, safely inside the cardinality limit.

6. Use Analysis filters to narrow to one year. Note that this filter lives on the view, not the page, so your other views are untouched.

7. Rename the view to Aged Accounts by Month.

Then, to see the hierarchy properly:

8. Add a second view. Put Posting Date Year, Posting Date Quarter, and Posting Date Month into Row Groups in that order, and Remaining Amount into Values.

9. Expand a year, then a quarter. Watch the subtotals appear at each level and the record count beside each group.

10. Use Copy link from the view's dropdown. In the dialog, look at the Company field: you can link to your current company or deliberately not link to any company at all. Recipients get prompted to name their own copy of the view.

How to See When Your SQL Server Backup or Restore Will Finish

noreply@blogger.com (Mohana) — Thu, 23 Jul 2026 07:09:43 +0000

If you've ever started a database backup or restore and then sat there wondering how much longer it'll take, you already know the problem. A large database can leave you staring at a spinning cursor with no idea whether you're waiting one more minute or another hour.

The good news is that when a backup or restore is running, SQL Server already knows roughly when it expects to finish. You just have to ask for it. This query does exactly that, and the column that matters most is estimated_completion_time.

Run this in a new query window while your backup or restore is going, and you'll get a row back for each active operation, along with a real clock time for when SQL Server expects to be done.

The script

SELECT
   session_id as SPID, command, a.text AS Query, start_time, percent_complete,
   dateadd(second,estimated_completion_time/1000, getdate()) as estimated_completion_time
FROM sys.dm_exec_requests r
   CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) a
WHERE r.command in ('BACKUP DATABASE','RESTORE DATABASE')

The star of the show: estimated_completion_time

This is the column that turns a nerve-wracking wait into something you can actually plan around.

Inside sys.dm_exec_requests, SQL Server exposes an estimated_completion_time value, but the raw number is the estimated milliseconds remaining. On its own, that's not very useful. Nobody wants to do mental math on "4,380,000 milliseconds" to figure out when they can go to lunch.

That's what this part of the query fixes:

dateadd(second, estimated_completion_time/1000, getdate())

It divides the milliseconds by 1000 to get seconds, then adds those seconds to the current time with getdate(). The result is an actual finish time, like 2026-07-23 14:52:10, instead of a raw count you have to interpret. You look at it and immediately know when the operation should wrap up.

The key thing is that this value is live. SQL Server recalculates it as the operation runs, so each time you execute the query you get a fresh estimate based on the work done so far. Run it, wait a bit, run it again, and you'll watch the projected finish time settle down as the operation progresses. That's your progress, right there in SSMS, without any external tool.

The percent_complete column tells you how far along you are; the estimated completion time tells you the one thing people actually care about, which is when this will be done.

You'll also need VIEW SERVER STATE permission to see this, since it reads from sys.dm_exec_requests and sys.dm_exec_sql_text. Most DBAs already have it, but a restricted login might not.

And if you want a running view, just keep hitting execute every few seconds. Watching that projected finish time creep closer is a lot less stressful than staring at a blank screen wondering if anything is happening at all.

Wrapping up

This is one of those small scripts worth keeping in your snippets folder. When you're running a backup or restore, it lets you see the progress directly in SQL Server and, more importantly, tells you when the operation will actually finish, so you can plan around it instead of guessing.

Approval Workflows for Item Journals and Requisition Worksheets

noreply@blogger.com (Mohana) — Wed, 18 Mar 2026 08:14:00 +0000

The Gap That Existed Until Now

If you've worked with Business Central approval workflows, you know the story. General journal batches had approval support baked in. But item journals? Requisition worksheets? Planning worksheets? Nothing. You either built custom workflows from scratch (not fun) or relied on trust and process discipline to make sure someone reviewed those entries before posting.

That meant inventory adjustments, consumption postings, and purchase document creation from requisition lines could happen without a second pair of eyes. And for organizations with audit requirements or segregation of duties policies, that was a real problem.

With BC28, Microsoft has closed this gap. Let's walk through what's new.

What's New in BC28:

Approval Workflows for Item Journals

Item journals now support the same batch-level approval workflow that general journal batches have had for a while. You can send a batch for approval before anyone can post it. This applies to four journal types:

Once a batch has an active approval request, the system locks it down. No edits, no deletes, no posting until the approval is completed or canceled. The standard approval actions (Approve, Reject, Delegate, Comments) show up right on the journal pages, along with the workflow status.

Approval Workflows for Requisition and Planning Worksheets

Requisition worksheets and planning worksheets now have full approval workflow support at the batch level. Before you carry out planning actions or convert requisition lines into purchase documents, the batch can go through an approval cycle.

When an approval request is active on a worksheet batch, the system prevents inserting, modifying, or deleting any requisition or planning lines. The workflow status is visible on the worksheet pages, and the same approval actions are available.

This is a big deal for procurement teams. Think about it: someone generates a planning run, the lines get reviewed and approved, and only then do they become purchase orders. No one accidentally carries out action messages on lines that haven't been vetted.

How It Behaves at Runtime

Here's what happens when a batch is pending approval:

If you try to modify a record that has an active approval request, BC will stop you with a message asking whether you want to cancel the approval first. It's the same pattern you already know from general journal approvals, just extended to new areas.

Setting It Up

Configuration follows the standard workflow setup pattern. No surprises here.

1. Open the Workflows page (search for it using Tell Me).

2. Select the Item Journal Batch Approval Workflow or Requisition Worksheet Batch Approval Workflow template.

3. Specify the template and batch name in the event conditions.

4. Configure your approvers and enable the workflow.

5. Open the relevant journal or worksheet and choose Send for Approval.

6. Track the status on the Approval Entries page.

These are standard workflow templates, which means they come ready to use. You're not building anything from scratch. Pick a template, point it at your batch, set up approvers, and go.

Power Automate Support

Microsoft has also updated the workflow events and responses to work with Power Automate. So if your organization uses Power Automate for approval routing or notifications, you can plug these new workflows into your existing flows. The integration follows the same pattern as other BC workflow events.

Allow Posting From/To DateFormula: No More Monthly Date Updates from Business Central v28

noreply@blogger.com (Mohana) — Fri, 13 Mar 2026 06:11:00 +0000

Business Central 28 introduces DateFormula-based posting period fields that automatically calculate your allowed posting range. Here's what changed, how it works alongside the existing fields, and what the code actually does.

The Problem Everyone Knows

If you've worked with Business Central for any length of time, you know the drill. Every month (or every period close), someone has to go into General Ledger Setup and manually update the Allow Posting From and Allow Posting To date fields. Same thing on the User Setup page for individual users who need different posting windows.

Miss it, and users can't post. Update it late, and someone might accidentally post into a closed period. It's a small administrative task, but it adds up, and it's surprisingly easy to forget.

What's New in BC28

With Business Central 2026 Release Wave 1 (BC28), Microsoft has added two new fields to both the General Ledger Setup table (Table 98) and the User Setup table:

New Field	Field No.	Type	What It Does
Allow Posting From DateFormula	205	DateFormula	Calculates the start of the allowed posting range dynamically
Allow Posting To DateFormula	206	DateFormula	Calculates the end of the allowed posting range dynamically

These fields use the standard DateFormula data type, the same one you see in payment terms, lead time calculations, and other places across Business Central. The system takes the work date, applies your formula, and determines the allowed posting window automatically.

No more monthly manual updates. Set the formula once, and the posting window moves forward on its own.

The Key Rule: DateFormula and Date Fields Are Mutually Exclusive

This is the most important thing to understand about this feature. You can use either the static Date fields or the new DateFormula fields, but not both at the same time. The code enforces this automatically.

How the mutual exclusivity works

If you set a DateFormula value, the system automatically clears the corresponding static Date field (sets it to 0D). And if you set a static Date value, the system automatically clears the corresponding DateFormula field (evaluates it to an empty string).

When you enter a DateFormula (say <-CM>), the trigger checks if the formula is not empty. If it has a value that clears the static date field to blank. Then it validates the date range.

Same thing in reverse. When you enter a specific date (say 03/01/2026), the trigger checks if the new date is not blank. If it has a value, it clears the DateFormula field by evaluating it to an empty string. Clean and simple.

The same pattern applies to the "Allow Posting To" (Field 3) and "Allow Posting To DateFormula" (Field 206) pair. The logic is identical.

Bottom line: You don't need to worry about conflicts between the old and new fields. The system handles it. Fill in one, and the other gets cleared automatically. They can coexist on the same page, but only one of each pair will hold a value at any given time.

Practical Example: Setting It Up

Scenario: Monthly Posting Window

Your company wants users to only post within the current month. Previously, you'd set Allow Posting From = 03/01/2026 and Allow Posting To = 03/31/2026 in General Ledger Setup, then remember to change both fields when April starts.

Field	Value	Meaning
Allow Posting From DateFormula	`<-CM>`	Beginning of the current month
Allow Posting To DateFormula	`<CM>`	End of the current month

With today's date being March 13, 2026, the system calculates:

Allow Posting From = March 1, 2026 (CalcDate of <-CM> from today)

Allow Posting To = March 31, 2026 (CalcDate of <CM> from today)

When April starts, the window automatically becomes April 1 through April 30. No one needs to touch it.

What Happens When You Post Outside the Range?

The error behavior is exactly the same as before. Whether the posting range comes from a static date or a calculated DateFormula, if the posting date on your document falls outside that range, you get the familiar error.

Error

"Posting Date is not within your range of allowed posting dates ...."

Note: Same fields available on User Setup.

Who Keeps Moving My Business Central Work Date?

noreply@blogger.com (Mohana) — Tue, 10 Mar 2026 06:14:00 +0000

Let me paint you a picture.

It's Monday morning. You fire up Business Central. You've set your Work Date to March 31st because you're doing month-end closing. Life is good. Then your session times out, or you refresh the browser, or you log back in after lunch and... your Work Date has changed to a completely different date. Not today. Not the date you set. Some other date entirely.

You set it again. Next login? Gone. Again.

"I could've sworn I set that to March 31st." Yeah, you did. BC just decided you were wrong.

The Crime Scene

After some digging (and a fair amount of yelling at my monitor), I tracked the problem to Codeunit 40 – LogInManagement, specifically a little procedure called GetDefaultWorkDate().

Here's what it looks like out of the box:

Codeunit 40 - LogInManagement.al

procedure GetDefaultWorkDate(): Date

See those highlighted lines? That's the culprit. For demo companies (Cronus, I'm looking at you), this procedure grabs the last G/L Entry's Posting Date and uses it as your default Work Date. Every single login. Every session refresh.

So whatever the Posting Date is on that last G/L Entry, that's your new Work Date now. Could be a date from three months ago. Could be a date in the future. Doesn't matter what you had it set to before. BC will keep resetting it to that G/L Entry date every time you log in or your session restarts. Like a toddler who keeps unbuckling their seatbelt.

But Wait, I'm Using a Demo Company for Real Work

And here's where it actually starts to hurt. A lot of consultants, partners, and even small businesses run on demo/evaluation environments that still have the IsDemoCompany() flag set to true. Maybe they started with Cronus and built on top of it. Maybe they're testing in a sandbox. Whatever the reason, they end up in this exact trap.

You're trying to do month-end, quarter-end, year-end... and every time your session refreshes or you log back in, BC pulls a "new phone, who dis?" on your Work Date.

The Fix

The solution is to subscribe to the OnAfterLogin event from Codeunit 150 "System Initialization". This event fires right after login, so we can step in and force the Work Date to today's date before the user even sees a page. Like civilized software should.

WorkDateFix.Codeunit.al

codeunit 50100 WorkDateHandler

{

[EventSubscriber(ObjectType::Codeunit,

Codeunit::"System Initialization",

'OnAfterLogin',

'', false, false)]

local procedure SetWorkDateOnLogin()

begin

// Override the G/L Entry-based Work Date

// and just use today's date like a normal person.

WorkDate(Today);

end;

}

That's it. That's the whole fix.

Wrapping Up

If you've ever logged into a Cronus or demo company and wondered why your Work Date keeps changing to a date you didn't set, now you know. It's not you. It's GetDefaultWorkDate() pulling the Posting Date from the last G/L Entry every time your session initializes, with all the subtlety of a sledgehammer.

Drop that event subscriber into your extension, and you'll never have to fight this particular battle again.

Create Purchase Orders from Drop Shipments

noreply@blogger.com (Mohana) — Mon, 09 Mar 2026 06:30:00 +0000

If you have worked with drop shipments in Business Central, you know the process has always been a bit... indirect. You would create a sales order, mark lines for drop shipment, and then separately create a purchase order and use the Get Sales Orders action to pull those lines in. It worked, but it was not exactly smooth, especially when you were juggling multiple orders.

With Business Central 2026 Release Wave 1 (BC28), Microsoft has simplified this workflow. You can now create purchase orders directly from the sales order itself using the Create Purchase Orders action. On top of that, drop shipment lines are now included in the Order Planning page when you calculate plans, and the Planning Worksheet page gets a dedicated Drop Shipment action group.

What Exactly Changed?

1. Create Purchase Orders Directly from Sales Orders

Previously, to create a purchase order for a drop shipment, you had to leave the sales order, go to the purchase side, and manually pull in the sales lines. Now there is a Create Purchase Orders action right on the sales order. Business Central looks at your drop shipment lines, figures out the vendor from the Item Card or Stockkeeping Unit Card, and suggests the purchase order lines for you. You review, tweak if needed, and you are done.

2. Drop Shipments Included in Order Planning

The Order Planning page now considers drop shipment lines when you run Calculate Plan. Before this update, drop shipment demand was essentially invisible to the planning engine. Now it shows up alongside your other demand, which gives you a more complete picture of what you need to order and when.

3. New Drop Shipment Actions in Planning Worksheet

The Planning Worksheet page now includes a dedicated Drop Shipment action group with Get Sales Orders and Sales Orders actions. This mirrors what the requisition worksheet already had, bringing consistency across the planning tools.

Tip: Vendor Determination

Business Central picks the vendor from the Item Card's Vendor No. field first. If you use Stockkeeping Units (SKUs), the vendor configured on the SKU for that location takes priority. You can always override it on the Create Purchase Orders page before confirming.

Before vs. After: Quick Comparison

Area	Before (BC27 and earlier)	After (BC28)
Creating POs from Sales Orders	Create PO separately, then use Get Sales Orders from the purchase order	Create Purchase Orders action directly on the sales order
Order Planning	Drop shipment lines not included in Calculate Plan	Drop shipment lines are included when calculating plans
Planning Worksheet	No dedicated drop shipment actions; only available in requisition worksheet	New Drop Shipment action group with Get Sales Orders and Sales Orders actions

Define Item Attributes for Item Variants

noreply@blogger.com (Mohana) — Sun, 08 Mar 2026 06:13:00 +0000

The public preview for Dynamics 365 Business Central 2026 release wave 1 (BC28) is now available, and there’s a feature in this release that many of us in the BC community have been waiting for. You can now define item attributes at the item variant level. It sounds simple, but if you’ve ever worked with variants in a real-world scenario, you know how much this changes things.

Let me walk you through what this feature does, how it works, and why it matters.

The Problem This Solves

Item variants have been a great way to keep your product list manageable in Business Central. Instead of creating a separate item for every color, size, or material variation, you set up one item and define the variants underneath it. A t-shirt in five colors? One item, five variants. Much cleaner than five separate item cards.

But here’s where it used to fall short: item attributes. Until now, attributes were only defined at the item level. So if your base t-shirt had an attribute of “Color: Blue,” all your variants inherited that same value. The red variant? Also said “Blue.” Not ideal.

You either had to live with inaccurate attribute data on your variants, or you gave up on variants entirely and created separate items just so each one could have the right attribute values. Neither option was great.

What’s New in BC28

With this release, you can assign attribute values that reflect the specific variant at the item variant level. Variants still inherit attributes from the parent item, but you can now adjust or remove those inherited values when a variant needs different information.

Here’s what that looks like in practice:

Key Capabilities:

• Assign attribute values directly to individual item variants

• Variants inherit attributes from the parent item automatically

• Adjust or remove inherited values per variant as needed

• New Item Variant Attribute Values page accessible from the Variants List or Variant Card

• New Update Variant Attributes action on the Item Card to force sync from item to variants

How It Works

Attribute Inheritance

When you add a new variant to an item, the attributes defined for that item automatically transfer to the variant. This is the inheritance part. If you’ve already set up attributes like Material, Weight, or Color on the parent item, your new variant gets all of those right away.

One thing to note: if no attributes are defined on the parent item, the variants will also be empty. The inheritance only works when there’s something to inherit.

Editing Variant-Specific Attributes

Once the attributes are inherited, you can open the new Item Variant Attribute Values page to review and edit them. You can get to this page from either the Item Variants List or the Item Variant Card. From there, you update or delete the inherited values so each variant shows the correct details.

So back to our t-shirt example: your parent item might have Color set to “Blue” (the default). When you create the “Red” variant, it inherits “Blue,” but you can immediately go in and change it to “Red.” Simple, clean, accurate.

Syncing Attributes with Update Variant Attributes

There’s also a new Update Variant Attributes action available directly from the Item Card. This lets you force a sync of attributes from the item down to all its variants. It’s useful when you’ve added or changed attributes on the parent item and want to push those changes out to existing variants without going through them one by one.

Create Purchase Quotes for Contacts in Business Central

noreply@blogger.com (Mohana) — Sat, 07 Mar 2026 14:07:00 +0000

The public preview for Dynamics 365 Business Central 2026 release wave 1 (BC28) is now available, and there are some really useful features in this update. One that caught my attention is the ability to create purchase quotes for contacts that aren't yet associated with a vendor. If you've worked in purchasing, you know the friction here. Let me walk you through it.

The Problem This Solves

Until now, if you wanted to create a purchase quote in Business Central, you needed to have a vendor record already set up. That sounds reasonable in theory, but in practice it creates unnecessary work. Think about it: you're exploring a potential purchase from a new supplier. You're not even sure the deal will go through. But before you can even draft a quote, you have to go create a full vendor record. That's wasted effort if the purchase never materializes.

How It Works

The concept is straightforward. You can now create a purchase quote and assign it to a contact that isn't linked to any vendor. Business Central lets you fill in the quote details, add your lines, and work with the document just like you normally would. The key difference is that you don't need a vendor number to get started.

Here's the step-by-step process:

1. Create a Purchase Quote and select a contact that isn't linked to a vendor. The Purchase Quote will be created without a Vendor No., and that's perfectly fine at this stage.

2. Choose a vendor template if multiple templates are available. Business Central selects the template based on criteria like territory code, country/region code, and contact type.

3. Enter the quote details as you normally would. Add your lines, quantities, prices, and any other information you need.

4. Release the quote or convert it to an order. At this point, Business Central automatically creates the vendor record using the template. The vendor is created only when you actually need it.

Why API Templates Don't Work on Business Central Custom API Pages

noreply@blogger.com (Mohana) — Sat, 28 Feb 2026 06:40:00 +0000

If you've ever tried to set up an API template for a custom API page in Business Central and wondered why nothing seems to apply, you're not alone. The Microsoft documentation mentions that API templates only work with a specific list of standard pages, but it doesn't really explain why. That's what this post is about.

What Are API Templates?

API templates let you pre-populate fields on new records created via a POST call to a BC API. The idea is simple: when someone creates a record through the API and doesn't supply every field, the template fills in the blanks.

You set them up in API Setup page, pick a Table/Page ID and a Template Code from your Configuration Templates, and optionally add conditions. Done or so you'd think.

The catch is in the docs:

API templates can only be set up with the following API pages: contacts, countriesRegions, currencies, customers, employees, itemCategories, paymentMethods, paymentTerms, shipmentMethods, unitsOfMeasure, and vendors.

API Pages That Support Templates (Out of the Box)
contacts
countriesRegions
currencies
customers
employees
itemCategories
paymentMethods
paymentTerms
shipmentMethods
unitsOfMeasure
vendors

Why Only Those Pages?

Microsoft's docs don't explain the reason, but the answer is in the code.

Every one of those supported pages calls a specific function in the OnInsertRecord trigger:

GraphMgtGeneralTools.ProcessNewRecordFromAPI(CustomerRecordRef, TempFieldSet, CurrentDateTime());

This is the function that actually looks up your API Setup configuration and applies the template values. Without it, the framework has no hook to do anything. The template gets ignored completely.

Here's the full OnInsertRecord from the standard Customer API page so you can see exactly how it's wired up:

trigger OnInsertRecord(BelowxRec: Boolean): Boolean

var

Customer: Record Customer;

CustomerRecordRef: RecordRef;

begin

if Rec.Name = '' then

Error(NotProvidedCustomerNameErr);

Customer.SetRange("No.", Rec."No.");

if not Customer.IsEmpty() then

Rec.Insert();

Rec.Insert(true);

CustomerRecordRef.GetTable(Rec);

GraphMgtGeneralTools.ProcessNewRecordFromAPI(CustomerRecordRef, TempFieldSet, CurrentDateTime());

CustomerRecordRef.SetTable(Rec);

Rec.Modify(true);

SetCalculatedFields();

exit(false);

end;

The key steps are:

1. Insert the record first (so it exists in the DB)

2. Get a RecordRef from it

3. Call ProcessNewRecordFromAPI, this is where the template lookup happens

4. Set the record back from the RecordRef so updated values come through

5. Modify the record to save everything

Custom API pages and the Resource API page don't have this plumbing, so templates never apply.

Seeing the Problem in Action

Let's prove this with the Resource API page. First, create a simple Configuration Template for Resources, say, one that sets a default Base Unit of Measure to HOUR.

Go to API Setup, add a new line, pick the Resource table or API page, and assign your template. Looks fine.

Now build Custom API Page from Scratch

page 50200 "My Custom Resource API"

{

PageType = API;

APIPublisher = 'mohana';

APIGroup = 'ap';

APIVersion = 'v2.0';

EntityName = 'resource';

EntitySetName = 'resources';

SourceTable = Resource;

ODataKeyFields = SystemId;

InsertAllowed = true;

DeleteAllowed = false;

ModifyAllowed = true;

layout

{

area(Content)

{

repeater(Group)

{

field(id; Rec.SystemId) { }

field(number; Rec."No.") { }

field(displayName; Rec.Name) { }

field(baseUnitOfMeasure; Rec."Base Unit of Measure") { }

field(type; Rec.Type) { }

}

Now POST a new resource via the API without specifying Base Unit of Measure:

POST /api/v2.0/companies({id})/resources

{

"number": "RES-TEST-01",

"displayName": "Test Resource"

}

Check the record that gets created. The Base Unit of Measure field is empty. The template did nothing.

That's because the Resource API page's OnInsertRecord has no ProcessNewRecordFromAPI code.

The Fix: Add the Missing code

page 50200 "My Custom Resource API"

{

PageType = API;

APIPublisher = 'mohana';

APIGroup = 'ap';

APIVersion = 'v2.0';

EntityName = 'resource';

EntitySetName = 'resources';

SourceTable = Resource;

ODataKeyFields = SystemId;

InsertAllowed = true;

DeleteAllowed = false;

ModifyAllowed = true;

layout

{

area(Content)

{

repeater(Group)

{

field(id; Rec.SystemId) { }

field(number; Rec."No.") { }

field(displayName; Rec.Name) { }

field(baseUnitOfMeasure; Rec."Base Unit of Measure") { }

field(type; Rec.Type) { }

}

var

GraphMgtGeneralTools: Codeunit "Graph Mgt - General Tools";

TempFieldSet: Record 2000000041 temporary;

trigger OnInsertRecord(BelowxRec: Boolean): Boolean

var

ResourceRecordRef: RecordRef;

begin

if Rec.Name = '' then

Error('Resource display name is required.');

Rec.Insert(true);

ResourceRecordRef.GetTable(Rec);

GraphMgtGeneralTools.ProcessNewRecordFromAPI(

ResourceRecordRef, TempFieldSet, CurrentDateTime());

ResourceRecordRef.SetTable(Rec);

Rec.Modify(true);

exit(false);

end;

}

With the extension published, run the same POST call again:

POST /api/v2.0/companies({id})/resources

{

"number": "RES-TEST-02",

"displayName": "Test Resource 2"

}

This time, open the resource record. You'll see Base Unit of Measure is populated with HOUR from the template, even though you didn't pass it in the POST body.

The template is working exactly as it should. The only difference is the three lines of code that hook into the template engine.

The TempFieldSet Variable

TempFieldSet is a temporary record based on the Field system table (table 2000000041). The ProcessNewRecordFromAPI function uses it to track which fields were explicitly set in the API call (as opposed to defaulted). This is how it knows which fields to leave alone and which to fill in from the template.

BC does not populate TempFieldSet automatically. You have to register each field manually by calling RegisterFieldSet from the OnValidate trigger of every field on your API page. If you skip this, ProcessNewRecordFromAPI has no record of which fields the caller actually sent, and it will treat all of them as update, meaning the template could overwrite values the API caller explicitly passed in.

Here's the pattern you need on every field:

field(type; Rec."Contact Type")

{

Caption = 'Type';

trigger OnValidate()

begin

RegisterFieldSet(Rec.FieldNo("Contact Type"));

end;

}

And the RegisterFieldSet procedure itself:

local procedure RegisterFieldSet(FieldNo: Integer)

begin

if TempFieldSet.Get(Database::Customer, FieldNo) then

exit;

TempFieldSet.Init();

TempFieldSet.TableNo := Database::Customer;

TempFieldSet.Validate("No.", FieldNo);

TempFieldSet.Insert(true);

end;

The Get check at the top prevents duplicate entries if the same field gets validated more than once. Every field you expose on the API page needs its own OnValidate trigger calling this procedure. If you miss a field, the template will overwrite whatever the caller sent for that field.

What If You Pass a Value That's Also in the Template?

The API caller always wins. ProcessNewRecordFromAPI only applies a template value if that field is not already in TempFieldSet. Since every field you explicitly send in the POST body gets tracked there, the function simply skips those fields when applying the template.

So if your template sets Type to Machine but your POST includes "type": "Person", the record gets Machine without TempFieldSet.

If your template sets Type to Machine but your POST includes "type": "Person", the record gets Person with TempFieldSet.

The template value is ignored for that field.

This matches what the Microsoft docs say about template ordering too:

Field values defined in the template are only applied to fields that have not already had a value defined, either explicitly in the API, or in a previously applied template in the order.

The same rule applies when you have multiple templates stacked in API Setup with different order numbers. The first template to set a field wins, and any later templates skip it.

Priority	Source	Wins over
1 (highest)	Explicit API value	Everything
2	Earlier template (lower Order #)	Later templates
3 (lowest)	Later template (higher Order #)	Nothing

Testing Your MCP Connection with Real Business Central Questions and Best Practices (BLOG 4 OF 4)

noreply@blogger.com (Mohana) — Thu, 12 Feb 2026 07:41:00 +0000

Validating Your BC MCP Setup with Real-World Queries

Introduction

Your BcMCPProxy is built, Claude Desktop is configured, and the BC MCP Server is live. Now let’s put it all to the test.

In this final post, we go beyond simple data lookups. The real power of connecting an AI agent to Business Central is not just reading records. It is asking business questions in plain English and getting visual, actionable answers. We will walk through two scenarios that demonstrate exactly that, followed by best practices for working with AI agents.

Scenario 1: Project Budget vs. Actual Analysis

This is where things get interesting. Instead of opening BC, navigating to project ledger entries, exporting to Excel, and building a chart manually, you just ask.

Prompt

"I want to see budget vs actual for all Projects

with a nice graphic view"

What Happens Behind the Scenes

Claude does not just make one API call. It thinks through the problem and executes multiple steps:

1. Claude identifies that it needs project data with budget and actual figures. It calls the BC MCP Server to read the Project API page.

2. It retrieves budget amounts and actual costs for all projects. If the data spans multiple API pages (project tasks, project planning lines, project ledger entries), Claude calls each one as needed.

3. Claude then generates an interactive chart, typically a grouped bar chart, comparing budget vs. actual for each project side by side.

4. The chart is rendered as a visual artifact directly inside Claude Desktop. No Excel export. No copy-paste. Just ask and see.

✅ Setup Note

For this scenario, I created a custom API page in Business Central that exposes the Job Planning Lines table with all the relevant budget and actual fields. The standard BC APIs do not include project planning data out of the box, so a custom API page was needed to give the agent access to this information. This is a common pattern: if the data you want is not available through standard APIs, build a custom API page, add it to your MCP configuration, and the agent can use it immediately.

Why This Matters

Think about how long this takes the traditional way. Open BC, navigate to the right page, apply filters, export to Excel, format the data, build a pivot chart, adjust colors and labels. That is 15 to 30 minutes of work, depending on how many projects you have.

With MCP, you type one sentence and get a visual answer in seconds. The agent handles all the API calls, data shaping, and visualization for you.

Expected result: A bar chart showing budget vs. actual cost for every project in your BC environment along with total budget, actual cost, remaining budget and budget utilization.

✅ Pro Tip

You can refine the prompt to focus on specific projects or add more detail. For example: "Show me budget vs actual for projects J00010 and J00030 with a breakdown by project task." The more specific your prompt, the more targeted the output.

✅ Prompt Refinement

If the initial chart does not look quite right, just tell Claude what to change. "Make it a horizontal bar chart instead" or "Add percentage variance labels" or "Only show projects that are over budget." The agent iterates on the visualization without you touching any code.

Scenario 2: Available Inventory Overview

Inventory visibility is one of those things that everyone needs but nobody wants to build reports for. Let’s skip the report.

Prompt

"Show me available inventory in a nice chart"

What Happens Behind the Scenes

1. Claude calls the BC MCP Server to read the Item API page and retrieves all items with their inventory quantities.

2. It filters for items that actually have inventory on hand (skipping zero-stock items to keep the chart clean).

3. Claude generates a visual chart. Depending on the number of items, it might use a bar chart for a smaller catalog or a treemap/bubble chart for a larger one.

4. The chart is rendered as an interactive artifact in Claude Desktop, with item numbers, descriptions, and quantities.

Why This Matters

This is a question that gets asked in every warehouse meeting, every sales call, and every planning session. Instead of logging into BC, navigating to the item list, sorting by inventory, and maybe exporting it for a visual, you just ask.

And because it is conversational, you can immediately follow up: "Which items are below their reorder point?" or "Show me just the items in the FINISHED category" or "What is the total inventory value?" The agent keeps the context and builds on the previous answer.

Expected result: A visual chart showing available inventory quantities across your items. Items with the highest stock levels are immediately visible. Zero-stock items are excluded for clarity.

✅ Taking It Further

Try chaining requests: "Show me available inventory, then highlight items that have not had any sales in the last 90 days." Claude can cross-reference inventory data with sales data across multiple API calls to surface slow-moving stock. This kind of ad-hoc analysis used to require a dedicated report. Now it is a conversation.

The Bigger Picture

These two scenarios are just the beginning. The pattern is always the same: ask a business question in plain English, and the AI agent figures out which BC API pages to call, fetches the data, and presents it visually.

Here are a few more ideas to try once your setup is working:

• "Show me a trend of sales order totals by month for the last 12 months."

• "Which customers have overdue balances? Show me a breakdown by aging bucket."

• "Compare actual vs. budget for GL accounts in the 6000 range this quarter."

• "What are our top 10 selling items by revenue this year? Show me a chart."

Each of these would traditionally require navigation, filtering, exporting, and charting. With MCP, they are one-line prompts.

Best Practices

Security

• Least privilege: Start with a read-only MCP configuration. Only enable write operations after thorough testing.

• No secrets in config: No passwords or secrets are stored. The proxy uses Azure’s delegated auth flow.

• Separate configurations: Create purpose-specific configurations (e.g., Finance-ReadOnly, Sales-ReadWrite).

• Audit access: Review who has the MCP - ADMIN permission set in BC.

Working with Agents

• Be precise: Agents work best with specific, clear requests. “Show me customers” is good; “Show me the top 10 customers sorted by balance” is better.

• Request complete data: When you need all records, say so explicitly and instruct the agent not to use the top parameter.

• Understand tool calls: Each MCP tool call is a separate API request. Complex queries may take a few seconds.

• Review before approving: For sensitive operations, the agent will ask for confirmation. This is by design.

Maintenance

• Stay current: The BC MCP Server is in public preview and may change. Watch the Microsoft Learn documentation for updates.

• Expand over time: As BC evolves, new API pages may become available. Add them to your MCP configuration to expand agent capabilities.

• Test after updates: If something breaks after a BC update, re-check Feature Management and MCP configuration.

Conclusion

Over these four posts, we have gone from understanding what AI agents and MCP are, through enabling the BC MCP Server and configuring it, to building a proxy executable and testing it with real business questions.

The key takeaway is this: the value is not in reading individual records. It is in asking business questions and getting visual, actionable answers in seconds. Budget vs. actual comparisons, inventory overviews, trend analysis. All of this is now a conversation, not a report-building exercise.

The BcMCPProxy is a temporary bridge. Microsoft will likely provide direct MCP client support in future releases. But it works today and demonstrates the enormous potential of agentic AI in the Business Central ecosystem.

The future is agentic. Let’s build it.

Blog Series Navigation

Blog 1: Understanding AI Agents and MCP

Blog 2: The Business Central MCP Server

Blog 3: Building BcMCPProxy.exe and Connecting to Claude Desktop

▶ Blog 4: Testing Scenarios and Best Practices (You are here)