Category: AL Extensions

Apr 08

OData Deprecation in Business Central: What Your Integration Architecture Needs Right Now

The Clock Is Ticking on Your OData Endpoints If you have integrations connecting to Business Central through OData web service endpoints, you need to start planning your migration today. Not next quarter. Not when v30 drops. Today. Microsoft has been signalling this move for years, but the concrete timeline is now clear. Version 30 (2027 Wave 1) will remove the ability to expose Microsoft-authored pages as OData endpoints entirely. Version 26 already shows warnings. Version 28 continues tightening. And SOAP endpoints? Those are being fully removed in version 29 (2026 Wave 2). This is not a minor API version bump. This is a fundamental shift in how Business Central expects external systems to communicate with it. And if you are running a multi-system architecture where BC is one node in a larger integration mesh, the impact goes well beyond swapping one URL for another. Why Microsoft Is Doing This (And Why They Are Right) The core argument is straightforward: UI pages were never designed to be APIs. They were designed for humans to interact with. When you expose a page like the Customer List as an OData endpoint, you are tying your integration to a contract that Microsoft never intended to be stable. Every time Microsoft updates the layout, adds a field, or restructures a page for user experience reasons, your integration is at risk of breaking. This has been a constant headache for years. Partners discover after an update that a field moved, a column disappeared from the default view, or a filter stopped working the way it used to. API Pages solve this by creating a purpose-built, versioned surface for programmatic access. They have explicit contracts. They are designed for throughput and filtering. They support proper versioning so that when Microsoft releases API v2.1, your v2.0 integrations keep working. From a design perspective, this separation between the human interface and the machine interface is exactly right. It just means a lot of work for everyone who took shortcuts. What Is Actually Changing: The Technical Timeline Let me break down the timeline with specifics: Version 26 (2025 Wave 1, already live): Warnings appear when you try to expose Microsoft UI pages as OData endpoints. SOAP endpoints for Microsoft pages are blocked by default. The telemetry signal RT0053 becomes available, which is your best friend for auditing what your tenants are actually calling. Version 28 (2026 Wave 1, current): Standard API surface continues to expand. New APIs arrive for sustainability, ESG reporting, and additional supply chain scenarios. OData deprecation warnings persist and become more prominent. Version 29 (2026 Wave 2): SOAP endpoints are fully removed. If anything still depends on SOAP, it will simply stop working. Version 30 (2027 Wave 1): OData support for Microsoft-authored pages is removed. Custom pages exposed as OData will still work, but Microsoft strongly recommends moving everything to API pages or API queries. There is also an important detail that often gets missed in discussions. Unbound Actions, which can currently only be called through OData (not the REST API), do not yet have a replacement in the REST API surface. This is a gap that Microsoft needs to address, and it is worth tracking closely. If your integrations use unbound actions on codeunits exposed through OData, you are in a particularly tricky spot. The Real Problem: It Is Not Just About Swapping URLs Most of the migration guides I have seen online focus on the mechanical steps. Find your OData endpoints, create equivalent API pages, update your connection strings. That is the easy part. The hard part is dealing with the knock-on effects: Different data shapes. API pages do not mirror UI pages. They expose a flatter, more predictable data structure. If your integration logic assumes the nested structure of an OData response from a page like the Sales Order, you will need to rethink your data mapping layer. Different filtering behaviour. API pages use OData v4 query parameters, but the available filter fields, supported operators, and response pagination differ from what you get when querying a UI page. Integrations that rely on complex filters need careful testing. Different authentication patterns. If you are moving from legacy OData with basic auth (still surprisingly common in on-prem to cloud migration scenarios), you will need proper OAuth 2.0 flows with Azure AD. This is a good thing, but it is also a significant change for some middleware setups. Rate limiting. The BC API enforces per-user limits of 6,000 OData requests per 5-minute sliding window, a maximum of 5 concurrent requests, and 100 simultaneous connections. If your integration was chatty against OData pages, you may need to rethink your request patterns. Missing API coverage. Not every entity that you can currently access through OData UI pages has a corresponding standard API. You will need to identify gaps early and plan to either build custom API pages or use API Queries for read-only scenarios. A Practical Migration Approach Here is how I would approach this in a real project, based on patterns I have used across integration implementations: Step 1: Audit Everything Before you write a single line of code, you need a complete inventory. Use the RT0053 telemetry signal in Application Insights to discover every external call hitting deprecated endpoints. This is not optional. You will be surprised at what you find. Middleware that someone set up three years ago and forgot about. A Power Automate flow that a functional consultant created. A reporting tool pulling data nightly. Run this across all your environments. Production, sandboxes, everything. If you do not have Application Insights configured, that is your actual first step. Step 2: Classify by Complexity Not all integrations are equal. Sort your discovered endpoints into three buckets: Simple swaps: The entity has a direct standard API equivalent. Customers, Vendors, Items, Sales Orders, Purchase Orders. These are relatively straightforward. Change the endpoint URL, adjust the data mapping, test, deploy. Custom API pages needed: The entity does not have a standard API, or your integration needs a specific data shape that the standard API does not provide. You will need to create custom API pages in a Per-Tenant Extension or AppSource app. Architectural rework required: The integration relies on patterns that do not translate directly. Unbound actions, complex multi-step operations that depend on page triggers, or scenarios where the integration was essentially screen-scraping a page through OData. Step 3: Design Your Custom API Pages Properly When you build custom API pages, do not just copy the structure of the UI page. Design the API for its actual consumers. Think about what fields the calling system actually needs. Think about the filters that will be applied. Think about whether an API Query would be better suited for read-only reporting scenarios. API Queries deserve special attention. They let you join data across tables and return exactly the shape your consumer needs, without the overhead of a full page object. For reporting integrations, data warehouse feeds, and analytics pipelines, API Queries are often the better choice. Step 4: Version From Day One One of the biggest advantages of API pages is versioning. Use it. Do not publish a custom API without a version number. When your requirements change (and they will), publish a new version alongside the old one. Give your consumers time to migrate. This is the discipline that UI pages as OData never gave you. The Unbound Actions Gap I want to call this out specifically because it is the one area where the migration story is incomplete. If you have integrations that call BC codeunits as unbound actions through OData, there is currently no REST API equivalent. Microsoft has not announced when or how this will be addressed. The practical options right now are: Wait and watch for Microsoft to fill this gap. This is risky if you are on a tight migration timeline. Wrap the logic in a custom API page with a bound action. This works for many scenarios but changes the calling pattern. Move the orchestration logic outside of BC entirely. Use Azure Functions or Logic Apps to coordinate the multi-step operations, calling individual API endpoints as needed. I lean toward option 3 for complex scenarios. It gives you more control, better error handling, and cleaner separation of concerns. But it is more work upfront. What This Means for Your Architecture If you are building new integrations today, the path is clear: use API pages, use the standard API v2.0, and design for the modern REST surface from the start. If you are maintaining existing integrations, start your audit immediately. Budget time for the migration in your 2026 and early 2027 planning cycles. Do not wait for the deadline. And if you are building middleware or integration platforms that connect BC to other systems, think about abstraction layers. Build your BC connector against the API surface with a clean mapping layer that isolates your business logic from the specifics of how BC exposes data. This way, when Microsoft eventually evolves the API further, your impact surface is contained. The deprecation of OData is not a crisis. It is Microsoft doing the right thing by separating the user experience from the machine interface. But it does require real effort, and the teams that start planning now will have a much smoother transition than those who wait until the warnings turn into errors.

Microsoft is removing OData support for first-party pages in Business Central v30 (2027 Wave 1), and SOAP endpoints disappear even sooner in v29. If your integrations rely on exposing UI pages as web services, the migration clock is already running. This post walks through the full deprecation timeline, explains why swapping URLs is only 20% of the work, covers the unbound actions gap that nobody is talking about, and lays out a practical four-step migration approach for teams managing multi-system architectures. Start planning now, not when the warnings turn into errors.

Apr 09

Implicit Conversion Between Record and RecordRef

With recent updates to the AL language extension (v15), Microsoft has introduced support for implicit conversion between Record and RecordRef instances, making it easier to work with both types in the code.

This feature removes some of the verbosity previously required when switching between Record and RecordRef variables, allowing developers to write cleaner, more concise AL code.

Mar 17

Ternary operator ?: in AL

AL language now supports ternary (conditional) operator. The ternary operator? : known from other programming languages, streamlines conditional operations in code, enhances readability and reduces verbosity. The following examples show how the code  GetBooleanText() can be rewritten using the ternary operator to be less verbose and more succint. Without the ternary operator: With the ternary operator …

Continue reading

Mar 13

Include Resources in extensions

Good news! Resource files can now be included as part of an extension. This new option enables developers to package essential resources, such as images, configuration settings, and text files, directly with their extensions, ensuring that all necessary components are readily accessible and improving overall performance. To add resources to the extension, the following property …

Continue reading

Mar 11

AL now supports the Continue statement

From runtime version 15, it is possible to use the continue keyword in loops to continue to the next iteration. (Please make sure that your “AL Language extension for Microsoft Dynamics 365 Business Central” is version 15.0 or above) The continue statement allows skipping the remaining code in a loop’s current iteration and jumping directly into the …

Continue reading

Mar 11

Multiline strings: AL now has support for multiline string literals.

AL now support multiline string literals. It will enhance code readability and maintainability, especially when dealing with lengthy text content or complex string literals. Functionality is available with the AL Language Extension version 15.0 I thought, “Oh, we can use this to store the prompts for Copilot or OpenAI.” However, Dmitry suggested that utilising the …

Continue reading

Mar 11

Do you know you can navigate directly to a symbol of a file in VS Code?

All you need to do is press “Ctrl” + P and type the object name you want to navigate to. Then press @. It will list all the object’s fields, functions, and triggers. You can select the place you want to jump into. Regards,Tharanga Chandrasekara

Feb 02

Are you looking for an Action image browser in BC?

AL developers for Microsoft Business Central need to browse the Business Central image gallery to select meaningful images. This allows them to assign these images to new action buttons, enhancing the user interface for better usability. The AZ AL Dev Tools extension simplifies this process by adding new commands that load and display available images …

Continue reading

Feb 02

Decluttering Your Enums: How to Show Only What Matters

It is common practice to use existing objects when developing new modules. Microsoft Dynamics 365 Business Central offers a wide array of pre-defined enums; however, specific options within these enums may not be relevant to the new module’s requirements. Additionally, there may be instances where it is advisable to restrict users from selecting specific values …

Continue reading

Feb 02

Business Central Performance Profiler

If a business process takes longer than expected, your administrator can use the Performance Profiler page to record a snapshot of the process. While recording, the profiler monitors all of the apps that are involved in the process.