Welcome to Central Perspectives, a Business Central podcast from ITrators. I'm Emma, here with Alex. We're AI hosts, and our scripts and voices are AI-generated. Today we're looking at changes that put useful information closer to a decision: choosing a report layout, reviewing an agent's work, and preparing the messages customers receive. There's also a platform change for the people keeping Business Central running, and a more specific discovery for businesses using self-billing. We'll separate what the product offers from what your own setup still needs to prove. Now, let's get started.

Let's start with a familiar decision: which invoice layout should a colleague choose? A company might have three similar options, including one it no longer wants to use. Business Central 29 expands layout-status control to layouts supplied with the product and through extensions. Statuses themselves aren't new. Alex, can the company now remove that unwanted choice without changing the extension that supplied it?

• What's New or Changed in Business Central 2026 release wave 2 - Update 29.0

It lets them narrow the choices people see on a report request page. Approved layouts are selectable; Draft, Pending Approval, and Retired layouts aren't. So, in your example, the company could retire an old layout instead of asking everyone to remember which of three similar names to avoid. And if that old layout comes from an extension, changing its status creates an override. It doesn't mean editing the extension's original layout file.

• Get started creating report layouts

That sounds more useful than adding another warning to the name. But suppose the new layout is finished, and the person who designed it says it's ready. Their colleague opens the report and can't find it. New user-defined layouts start as Draft, so could the design be perfectly healthy while its status is doing exactly what it's supposed to do?

• Get started creating report layouts

Yes. I'd check the status before asking someone to rebuild the file. A layout can exist without being offered as an ordinary choice. The useful handover is therefore not just, here's the finished design. It's, here's the design we've checked, and here's the decision to make it available. In that situation, approving the layout solves an availability problem; it doesn't repair a broken design, because we haven't established that the design is broken.

• Get started creating report layouts

I want to stay with that word, approving. A finance manager might hear Pending Approval and imagine a request appearing in their inbox, with someone else prevented from approving their own work. The source documents the statuses, not that whole process. What would you put around the feature without turning a modest improvement into an approval-system project?

• Get started creating report layouts

A named owner and an agreed check could be enough. For example, the designer prepares a revised invoice, and the person responsible for customer documents checks a sample before its status changes. That's a proposed working arrangement, not an automatic workflow promised by the status field. If the business genuinely needs separate approvers, enforced routing, or a particular audit record, those are additional requirements to verify. I wouldn't assume either that this feature provides them or that every company needs them.

• Get started creating report layouts

Coming back to the colleague choosing an invoice layout: fewer choices aren't always better. Suppose this company needs two versions for different recipients, but only one was recently redesigned. I wouldn't want a tidy-up to remove a useful option just because it's older. How do we decide what that colleague should still be able to choose?

The job each layout still needs to do. In that case, I'd keep both legitimate choices approved and make their purposes clear to the person selecting them. Retire the genuinely unwanted option, not automatically the oldest one. For an extension-provided layout, the status override lets the company make that availability decision without modifying the supplied file. The aim is a usable selection, not the smallest possible number of layouts. Your second recipient gives us a reason not to over-simplify it.

• Get started creating report layouts

There is another label a listener may already know: Obsolete. If a layout is obsolete, it's tempting to treat that as the same thing as retired and move on. But Microsoft describes obsolescence as a signal that something may be removed later. For the colleague choosing a report today, which distinction matters?

• Get started creating report layouts

Retired is the status that removes it from that request-page selection. Obsolete communicates a different lifecycle message; for extension layouts, that obsolescence is defined in AL code. So I wouldn't use the words interchangeably in a handover. Saying we no longer want employees selecting this layout is an operational decision. Saying its publisher has marked it for possible later removal is information about its future. One can prompt the other, but they aren't the same setting.

• Get started creating report layouts

Our colleague still has those two legitimate recipient choices. Now imagine one recipient needs a different instruction printed on the invoice. The finance team likes the supplied layout otherwise, so they ask for a small wording change rather than a new design. That is a different request from hiding an unwanted option. Do they have to ask someone to modify the extension, or can they work from what is already there?

They can use the supplied layout as a starting point for a user-defined copy. The guide is explicit that you can't directly modify or replace an extension-provided layout. When you select one for editing, it offers to edit a copy instead. That copy can then be customized. This is an existing route, not another new version 29 feature. For your wording request, the copy changes the document's content. A status override only changes whether the supplied layout is offered for selection. It can't insert the recipient's instruction.

• Get started creating report layouts

I'd want the copy's name to explain that recipient need, not just say new invoice. Otherwise, we have recreated the original problem with another plausible choice. And I'd leave a short explanation of the changed wording for whoever looks after these documents next. They need to know whether it is a deliberate instruction or an accidental difference, especially if somebody later suggests using the supplied layout again.

That explanation gives the next person something to preserve or deliberately reconsider. I'd identify who owns the recipient instruction and who maintains the copy, rather than assuming the extension publisher now owns our alteration. Nor would I promise that a copy automatically picks up later changes from the extension. Once the user-defined version is ready, its status still matters: new layouts start in Draft and need approval to become selectable. Our colleague should see a clearly named, intended choice, not an unfinished experiment beside the supplied one.

• Get started creating report layouts

The override is the part I particularly like. The company doesn't have to own a modified extension just to stop offering an unwanted layout. I would still want to know what happens after that extension is updated, though. Does today's documentation settle that, or is that one of the things the company's own update check needs to establish?

• Get started creating report layouts

We know the original layout stays unchanged and the status is stored as an override. The guide doesn't promise how every extension update will behave, so I'd recheck the relevant choices after an update. And this is control over request-page selection, not a claim that every custom or background reporting path is blocked. For our colleague, the practical result should be simple: the layouts they need are available, and the unwanted one is no longer offered.

• Get started creating report layouts

The next question is who needs to prepare for a platform change. On 19 October, Microsoft announced that supported Business Central releases are moving from .NET 8 to .NET 10, online and on-premises. It also says most customers aren't expected to need application changes solely because of that move. Alex, who actually has work to do here, and who can carry on as usual?

• Business Central is transitioning to .NET 10 (19 October 2026)

Start with the people responsible for the environment and its technical dependencies, rather than asking everyone to prepare for a rewrite. The runtime is part of the software foundation underneath the application. If you're a user entering an order, this announcement doesn't give you a new order-entry procedure. If you're responsible for custom .NET components, development tools, or automated testing, it gives you a compatibility question. The work should follow those dependencies, rather than giving every department the same migration task.

• Business Central is transitioning to .NET 10 (19 October 2026)

For the online customer, Microsoft manages the transition. That should remove a fairly large piece of the work. But the announcement says it may involve an internal environment migration during the configured maintenance window. So the useful question isn't, who will install .NET on my server? It's whether the window still matches when the business can tolerate maintenance.

• Business Central is transitioning to .NET 10 (19 October 2026)

Yes, especially if the business's working hours have changed since that window was chosen. Microsoft recommends minimizing potential impact. That's preparation, though, not an outage forecast. And the announcement doesn't tell us whether a particular tenant has already moved. I'd verify the environment's position rather than announce completion or disruption from the headline.

• Business Central is transitioning to .NET 10 (19 October 2026)

On-premises has a more specific version detail. Microsoft names cumulative update 27.12 for Business Central 27, and 28.6 for Business Central 28. I can imagine someone reading that as, we're on 28, so our requirements are settled. What would you want to see before accepting that answer?

• Business Central is transitioning to .NET 10 (19 October 2026)

The exact cumulative update they're running, and the requirements for the update they intend to install. The major version alone is too coarse here because the runtime support changes within those release families. I'd ask whoever owns the environment to connect those two facts before changing dependencies. If a test environment uses a different update from production, record that difference too. Otherwise, a successful test may be reassuring without answering the compatibility question we actually meant to ask.

• Business Central is transitioning to .NET 10 (19 October 2026)

Let me complicate that with a hypothetical development team. Their business users are on the online service, so Microsoft handles the environment transition. But the team builds and tests an extension using containers. Would you still put them in the group that needs to look at its own tooling, even though nobody is operating a production server?

• Business Central is transitioning to .NET 10 (19 October 2026)

I would. Online production doesn't make their development environment somebody else's responsibility. Microsoft's guidance explicitly includes container images, AL development tools, and automated build or test pipelines. For that team, I'd first identify the runtime its chosen image expects and whether the tools and dependencies match it. Then run the normal build and relevant tests. That's much more useful than updating everything indiscriminately, and it gives a failed check a place to start.

• Business Central is transitioning to .NET 10 (19 October 2026)

And if the business asks what improvement they'll notice on Monday morning, we shouldn't turn a newer runtime number into a performance promise. This announcement doesn't give a measured speed increase. There is still useful news here, though: it tells the technical owner where to spend attention, without asking everyone else to prepare for a different application.

• Business Central is transitioning to .NET 10 (19 October 2026)

I'd ask that owner to show which relevant operation they tested, not just whether sign-in worked. An infrequently used custom component could otherwise be missed. If a check fails, keep the diagnostic evidence and investigate that dependency. The timing alone doesn't prove .NET caused it. That gives the team a useful next step without turning the runtime into a catch-all explanation.

• Business Central is transitioning to .NET 10 (19 October 2026)

Let's take one purchase invoice that an agent has helped prepare. The person opening it needs to decide whether its suggested values are right before completing the review. In Business Central 29, that review is generally available directly on the document page, with a bar identifying agent changes. Alex, where should our reviewer begin on this invoice?

• Supervise Agent Activities in Business Central
• What's New or Changed in Business Central 2026 release wave 2 - Update 29.0

Start with the values the agent changed. The review list takes you to those fields, and each suggestion can show the agent's reasoning and confidence. In this example, suppose one value looks unfamiliar. Open its details while keeping the invoice in view, then compare the suggestion with what this purchase actually concerns. The useful change is that the reviewer can investigate that value in context, instead of treating the invoice as one unexplained result.

• Supervise Agent Activities in Business Central

On that invoice, a number beside Review tells us how many fields the agent modified. If it says six, that's six fields, not six invoices or six tasks. Useful for finding the changes, but not for deciding how quickly we can finish. One of those six values could matter much more than the others.

• Supervise Agent Activities in Business Central

Then let's stay with the unfamiliar value rather than race through the six. I'd ask: why did the agent suggest it, and does that reason fit this invoice? The suggestion details help with the first question. The purchase itself has to answer the second. A plausible explanation is useful evidence, but it isn't the same as a correct value.

• Supervise Agent Activities in Business Central

Orange marks lower confidence, which is an understandable invitation to slow down. My concern is the quiet white marker beside it. A busy reviewer could easily start treating white as already checked. If the explanation says a value was chosen from vendor history, what question would you ask before accepting it on today's document?

• Supervise Agent Activities in Business Central

Whether today's transaction actually resembles the history the suggestion relies on. Perhaps the vendor usually supplies one kind of service, but this invoice is for something else. That's a hypothetical exception worth testing against the source document. The explanation makes the assumption visible, which is valuable even when you reject the proposed value. I'd change the value if needed, rather than trying to persuade myself that a standard-confidence marker means this exception can't exist.

• Supervise Agent Activities in Business Central

Suppose our reviewer has now checked the suggested values and corrected the one that didn't fit. The next decision is whether the review is complete. Done and Dismiss can both leave the page looking tidier, but they don't mean the same thing. What is the reviewer saying when they choose Done rather than close the bar?

• Supervise Agent Activities in Business Central

Done completes the review, records your name and the date, clears the suggestion markers, and allows the agent's task to proceed. Dismiss hides the bar and refreshes the page to clear the markers; it isn't the documented completion action. So I'd teach the decision before the button: am I saying I've completed this review, or am I clearing the review interface? And neither label should be translated into a universal promise that an invoice has now been posted.

• Supervise Agent Activities in Business Central

Now imagine a colleague picks up that same invoice later. The suggestion markers have gone, but the colleague doesn't know whether the reviewer chose Done or Dismiss. They need to know where the work stands, not just inspect a tidy page. Where should they look for the agent's history on this invoice?

• Supervise Agent Activities in Business Central

Open the relevant agent's task in the Tasks pane. Its timeline shows the steps the agent completed and the step that needs input. That gives the colleague a place to check the work's progress instead of guessing from missing markers. We now have two useful views of the same invoice: the document for judging its values, and the task for understanding the agent's progress.

• Supervise Agent Activities in Business Central

That handover depends on what the colleague can access. Microsoft says the review bar can identify agent-influenced data even when someone doesn't have permission to use that agent. In that case, the controls for opening its task are hidden. So the colleague might see who influenced the invoice but still be unable to open the history they need.

• What's New or Changed in Business Central 2026 release wave 2 - Update 29.0

Then involve someone with the appropriate agent access to check that task. The colleague's question is whether work on this invoice still needs attention; it isn't a reason to give everybody broader permissions. Seeing agent-influenced data on the document and being able to inspect the task are separate capabilities. The handover should account for that difference.

• Supervise Agent Activities in Business Central
• What's New or Changed in Business Central 2026 release wave 2 - Update 29.0

One last thing for our original reviewer before they choose Done: a check on the invoice itself. The agent's suggested values aren't the only things the reviewer may need to notice. Ordinary page notifications are hidden while the review bar is present, with a Show other notifications link to reveal them. So our reviewer could finish checking those six fields and still need to read a separate warning about the document.

• Supervise Agent Activities in Business Central

You can open those notifications without leaving the review. Dismissing one doesn't complete the agent review, and selecting Done or Confirm doesn't require every notification to be resolved. A business validation can still block an action, though. So I'd read the relevant warning now, rather than assume the completed field review has dealt with it.

• Supervise Agent Activities in Business Central

For the invoice we started with, I think the useful result is quite concrete. The reviewer can explain why that unfamiliar value was wrong for this purchase, correct it, and make a deliberate decision to finish the review. They haven't just made the page look cleaner. Does that capture what the new on-page review helps them do?

Yes. The value, the explanation, and the purchase context are close enough to assess together. Once satisfied, the reviewer uses Done to record completion and let the task proceed. If a colleague later needs to understand the agent's progress, they know to check the task rather than infer it from the page's appearance. That's the improvement: less hunting for context, without pretending the review decision has disappeared.

• Supervise Agent Activities in Business Central

Now to something customers outside the company actually read: payment reminders. The news in Business Central 29 isn't that reminder emails have suddenly been invented. It's that the new communication texts for reminder terms are mandatory and can no longer be switched off in Feature Management. Alex, what should the finance team look at before its next reminder run?

• Optional Features Now Mandatory
• Set Up Reminder Terms and Levels

The communication the customer will receive: both the email body and the attached reminder. I'd start with the reminder terms the company actually uses, then look at the text for the relevant levels and languages. Mandatory means this text capability is part of version 29 without an off switch. It doesn't mean Business Central has chosen a collections policy or started emailing customers. The immediate preparation is to make sure the company's intended wording reaches the actual output.

• Optional Features Now Mandatory
• Set Up Reminder Terms and Levels
• Automate reminders in collections

The setup allows one set of messages across all levels, or particular messages for individual levels. Imagine a company that wants the first reminder to sound like a helpful nudge and the second to make the next action clearer. I wouldn't want the attachment to be firm while the email still reads as though nobody has contacted the customer before.

• Set Up Reminder Terms and Levels

That's a good reason to review them as a pair. For each level, ask what the customer should understand and do next, then check whether the email and attachment support that same request. The texts don't have to repeat each other word for word. One can be a short introduction and the other carry the detail. But if they imply different stages in the conversation, the customer has to interpret a contradiction the company could have removed beforehand.

• Set Up Reminder Terms and Levels

Before we write that firmer second-level message, how do we know it is the second level? Stay with one customer and one overdue invoice. Someone in finance says they have emailed the customer twice, and now they want the next reminder to sound more serious. That tells us something about the conversation, but does counting those emails tell us which reminder level Business Central will use?

Not by itself. The relevant product history is recorded when a reminder is issued. Its level is registered on reminder entries linked to the customer ledger entries. When another reminder is needed, Business Central checks the history linked to open entries, finds the highest level and uses the next level's conditions. That's existing reminder behavior, not a new escalation engine in version 29. For our overdue invoice, I'd inspect that issued history before assuming the next document will use the wording someone has just called second reminder.

• Set Up Reminder Terms and Levels

Let's say we've checked that history, and this customer has reached the highest level the company configured. The finance team has called that message final reminder. I'd read that as a promise about what happens next, not just a stronger heading. If the invoice remains unpaid, does reaching the last configured level mean that exact message cannot come around again?

No. If more reminders are created than there are defined levels, the highest level's conditions are used again. The reminder terms' Max. No. of Reminders setting limits how many can be created. So the highest configured level and the last reminder the company can create are not necessarily the same thing. If that top level has its own communication text, I'd check whether its wording still makes sense when the level is reused. A heading shouldn't make a stronger promise than the process supports.

• Set Up Reminder Terms and Levels

I wouldn't want our customer receiving a final reminder, then another final reminder a week later. Even if every amount is right, the company's wording starts to look unreliable. I'd rather have a clear request with a contact route than borrow a dramatic label from a template. Or, if final really is intended, agree what the team will do after it.

That is a decision for the finance owner, not something a heading settles. For this customer, I'd put the issued history, the proposed next level and its email and attachment together. If the highest level might repeat, read the message with that possibility in mind. Then keep the request consistent wherever it appears. We have moved beyond whether the text sounds polite or firm to whether it truthfully represents the next step.

• Set Up Reminder Terms and Levels

The language detail is more than a proofreading issue. Microsoft says the attachment texts and email texts should have matching language sets. With more than one reminder level, a mismatch can prevent the automation from customizing a message correctly. Suppose the company has prepared English email wording but only Danish attachment wording. Translating one screen hasn't finished the job.

• Set Up Reminder Terms and Levels

I'd compare the sets using Overview communications, then test the combination that matters to the customer. In your example, that means looking for English in both places, not simply proving that an English translation exists somewhere. And I'd include the later reminder level in the check. A first-level message that looks right doesn't establish that the second-level text is connected correctly. We don't need every imaginable permutation, but we do need the languages and stages the business really sends.

• Set Up Reminder Terms and Levels
• Automate reminders in collections

Let's say those texts look correct in setup, but the sample email still doesn't contain the wording the team expects. At that point, rewriting the text seems like a fairly unhelpful response. The guide also connects this to report selection and the Email Body Layout Name. Is that the next part of the path you would inspect?

• Automate reminders in collections

Yes. The configured text is one part; the selected output layout is another. The guide explains that the email text is inserted into the report chosen for the email body. I'd follow that connection before changing wording that is already correct. The same check should include the attached reminder, because seeing the right email body doesn't establish that its attachment is right too.

• Automate reminders in collections

So I'd ask for the customer's view, not a screenshot of the settings. Open the message, read the attachment, and answer one simple question: would I know what this company is asking me to do?

And if I disagree with the balance, would I know how to raise it? That doesn't require an elaborate message, just an intentional one. In a hypothetical review, I would have the person responsible for customer communication read the output alongside the finance owner. One checks whether the request is understandable; the other checks whether it represents the intended stage and facts. A technically populated template can still be a poor conversation with a customer.

What if the company already uses these communication texts, and the messages look right? The feature becoming mandatory sounds like a deadline, but I don't see a reason to rewrite a perfectly useful reminder just to mark the occasion.

• Optional Features Now Mandatory
• Set Up Reminder Terms and Levels

Neither do I. Check the output through the update and keep what works. Making these texts mandatory doesn't require a new reminder process. The existing Create, Issue, and Send actions still differ: issuing has customer-ledger consequences, and sending requires configured email. But our question today is the message, not how far to automate. For each reminder level and language the company uses, does the customer receive the intended request in both the email and its attachment?

• Optional Features Now Mandatory
• Automate reminders in collections

Our final discovery is narrower, but it answers a very specific accounting question. Business Central 29 lists vendor-specific numbering for self-billed invoices as a public preview, not generally available. Core self-billing was already generally available in the June 28.2 update. Before we get into the numbers, who is creating the invoice in a self-billing arrangement?

• Register a new vendor
• What's New or Changed in Business Central 2026 release wave 2 - Update 29.0

The buyer creates a purchase invoice on the vendor's behalf under a self-billing agreement. It isn't simply a buyer deciding that waiting for an invoice is inconvenient. The preview enhancement lets the vendor have its own self-billing number series. For a business already using that agreed process, separate sequences may make the documents easier to distinguish by vendor. The first question is whether that distinction serves the arrangement, not whether a new field is available to fill in.

• Register a new vendor

And which number changes? There is a trap in calling everything the invoice number. The guide says this series supplies Vendor Invoice No., while the posted purchase invoice still has its own normal number. If we don't separate those, two colleagues could describe the same document quite differently.

• Register a new vendor

Exactly which field you're discussing matters here. Imagine a self-billed invoice receiving a vendor reference from that vendor's sequence. Business Central still assigns the posted purchase invoice's own number from the normal Posted Invoice Nos. series. You're not replacing the company's entire posted-invoice numbering scheme with separate vendor schemes. In a trial, I'd inspect both identifiers on the resulting document. Otherwise, a team could look at the unchanged internal number and conclude that its vendor-specific setup hadn't worked.

• Register a new vendor

Does every self-billing vendor need a separate sequence, then? Or can the company keep a common one where that still makes sense?

• Register a new vendor

There's a documented fallback. The vendor-specific Self-Billing Invoice Nos. setting takes precedence. If it's blank, Business Central uses Posted Self-Billing Inv. Nos. from Purchases & Payables Setup. If both are blank, you can't post the self-billed invoice. So a common sequence is a real setup option, not necessarily a missed configuration step. I'd choose the approach that fits the agreed process, then test the expected reference for a vendor with an override and, if relevant, one using the fallback.

• Register a new vendor

When would you inspect that reference? If I open a draft purchase invoice and see that it is marked as self-billed, I might assume the numbering check is finished. But recognizing the kind of document and seeing the final reference are different things. At which point does the guide say that vendor number is assigned?

On posting. Creating the purchase invoice for the configured vendor, either directly or from an order, marks it as self-billed. The guide places assignment of the vendor-specific Vendor Invoice No. at posting. So a draft alone doesn't establish the final numbering result. In the contained evaluation, I'd inspect the posted vendor reference alongside the separate internal invoice number.

• Register a new vendor

Later, suppose the buyer and this vendor agree to stop self-billing and return to supplier-issued invoices. The person maintaining the vendor card clears its dedicated number series, thinking that removes the self-billing setup. But we just learned that an empty vendor series can mean use the shared one. That seems an easy change to misunderstand.

• Register a new vendor

Yes. Clearing that series alone doesn't turn off the agreement setting. While self-billing remains enabled, the global fallback can still supply the number. Microsoft says to clear Self-Billing Invoice Nos. before turning off Self-Billing Agreement on the vendor. Those are separate setup actions. And neither action substitutes for the buyer and vendor agreeing their new arrangement. I'd make the intended change explicit before someone edits the card.

• Register a new vendor

And I'd ask about invoices already being prepared when the arrangement changes. Otherwise, purchasing could expect the supplier to send an invoice while accounts is still preparing one on the supplier's behalf. Knowing which date the parties agreed is useful, but somebody still has to identify the unfinished work.

That's the handover I'd want the two teams to settle. The guide gives the order for changing the vendor settings; it doesn't establish what happens to every invoice already in progress. I wouldn't assume a toggle cancels those documents or rewrites posted references. Identify the unfinished invoices and agree who will issue each one. Then the configuration change supports a known process instead of leaving both sides guessing.

• Register a new vendor

While that self-billing arrangement is active, there's another document-flow restriction. Microsoft says a business can't receive inbound accounts-payable e-documents for vendors with a self-billing agreement. For a company already receiving electronic supplier invoices, that restriction needs attention before anyone treats this as a harmless numbering preference.

• Register a new vendor

That moves the document flow ahead of the numbering test. If the company expects this vendor to keep sending accounts-payable e-documents, it has a process conflict to resolve first. The people responsible for the agreement and purchasing need to settle the intended arrangement. A neat number series can't do that for them, and a configuration change shouldn't quietly decide it.

• Register a new vendor

The guide also says posting can create Digital Vouchers in the Danish version when self-billing is enabled. That's a localization detail, not a promise for every country. And despite the detailed setup instructions, the vendor-specific numbering enhancement is still listed as public preview. A how-to page doesn't turn a preview into general availability.

• Register a new vendor
• What's New or Changed in Business Central 2026 release wave 2 - Update 29.0

For a business that needs this, the next useful step is a contained evaluation in the relevant version and localization, with the agreement and document flow understood first. Check the vendor reference, the internal posted number, and the resulting document. Don't infer legal sufficiency from a checkbox or report layout. And for a business that doesn't use self-billing, there's no project hiding here. It's a specific option to recognize when the need appears, not a new standard everyone must adopt.

• Register a new vendor
• What's New or Changed in Business Central 2026 release wave 2 - Update 29.0

We've found some useful ways to make decisions clearer today: managing an extension layout's availability without changing its file, completing an agent review deliberately, and checking the message a customer actually receives. We also separated a Microsoft-managed runtime transition from the compatibility work a technical team may still own. Not everything calls for a new project, and the self-billing numbering option remains a preview. The useful next step is the one that answers a real question in your own setup. Thanks for listening to Central Perspectives from ITrators.

• Business Central is transitioning to .NET 10 (19 October 2026)
• Get started creating report layouts
• Supervise Agent Activities in Business Central
• Optional Features Now Mandatory
• What's New or Changed in Business Central 2026 release wave 2 - Update 29.0