Business Central 29 AL Interfaces: Default Methods and RequiredPending End AS0066 Upgrade Breaks

The feature appears as entry 573352 on Microsoft's AI at Work roadmap. The entry is marked Launched, lists General Availability in October 2026 for the Worldwide (Standard Multi-Tenant) cloud, and covers the web platform. It's also listed under Development in Microsoft Learn's notes for Business Central update 29.0, the public preview of the 2026 release wave 2.

What's changing​

Microsoft's description has two parts:

• Default method bodies on interfaces. An interface method can now include an implementation. Code that already implements the interface keeps working without changes.
• A path to a required method. A new RequiredPending transition attribute, together with AppSourceCop analyzer rules, lets a publisher signal that a method will become mandatory in a future version. Dependent developers get time to adopt it before the requirement takes effect.

Microsoft says the business value is that publishers can add behavior to an interface without forcing every implementing extension to change right away. That should mean fewer disruptive interface upgrades.

What Microsoft hasn't published yet: the exact AL syntax for a default body, the rule IDs for the new analyzer checks, the diagnostics developers will see, and the number of versions a method can stay "pending." Anyone who shows you confident sample code today is guessing. Wait for the feature documentation that should arrive with GA.

Why this matters: AS0066​

To see why this is a big deal, look at how interfaces have worked until now. Microsoft's Interfaces in AL documentation says an interface doesn't contain any code, only signatures, and can't itself be called from code, but must be implemented by other objects. It also notes that the AL compiler checks to ensure that implementations adhere to assigned interfaces.

That compiler strictness is useful, but it has a cost. If a publisher adds a method to an interface, every codeunit that implements it suddenly fails the contract. Microsoft enforces this with AppSourceCop error AS0066. The rule flags any new method added to an already published interface, because dependent extensions may break. The only fix it suggests is to put the interface back the way it was.

So until now, the real choices were:

1. Freeze the interface for good.
2. Publish a new interface that extends the old one. Microsoft has supported this since Business Central 2024 release wave 2, but anything implementing the new interface must implement every inherited method as well as the new ones.
3. Break your dependents and deal with the support tickets.

Default implementations add a fourth option: add the method, ship a sensible fallback, and let implementers override it when they're ready.

Microsoft's own guidance already pointed this way. The same Interfaces in AL page that says interfaces hold only signatures also advises developers to consider using default implementations for methods in interfaces to reduce boilerplate code. That advice is now backed by a language feature instead of only by workarounds.

Don't confuse it with the enum property​

AL already has a feature called DefaultImplementation. It's a different thing.

That property applies to enum types and, according to Microsoft, specifies the default implementer for the enum value if there is no explicit implementer set for the value. It was built for a related compatibility problem: adding a new interface to an existing, extensible enum, requires that all extensions of that enum provide an implementations for the interface, which is a breaking change.

The enum property works at the level of which codeunit handles a given enum value. The new feature works one level down, at individual methods on the interface itself. You'll probably end up using both.

The pattern developers have been building by hand​

Community developers have wanted this kind of staged migration for a long time. In 2020, when interfaces were new, James Pearson described a pattern where "We're introducing an interface and a default implementation. The default implementation calls the existing events so custom development will continue to work. Then we and dependent developers can migrate over to the interface over time."

That's the same idea: ship a fallback, then move people over gradually. Until now it took extra codeunits and conventions. With RequiredPending, the compiler and AppSourceCop are expected to handle it as part of the language. The analyzers can warn implementers that a method is coming before it becomes required, so the notice lives in the toolchain instead of in release notes nobody reads.

Practical guidance for AL developers​

If you publish interfaces (ISVs, AppSource publishers, platform teams):

• Make a list of the interfaces you've kept frozen because of AS0066. Those are the first candidates once the feature reaches GA.
• Choose defaults carefully. A default body is behavior that every existing implementer inherits without asking for it. A no-op or a conservative fallback is usually safer than something clever.
• Plan a deprecation-style timeline for any method you mark RequiredPending, and tell your dependents about it. The analyzers help, but they don't replace communication.

If you implement other people's interfaces:

• Expect new analyzer diagnostics pointing at pending methods. Treat them like obsolete warnings: work you can schedule now, before the next major version makes it urgent.

To evaluate it now:

• Microsoft Learn says the update 29.0 public preview applies only to Business Central online sandbox environments, not production or on-premises.
• You can create a new sandbox with the version set to 29.0 preview. You can also update an existing sandbox to the preview, which lets you test with your own extensions installed.
• Preview features aren't intended for production and may have restricted functionality.
• Microsoft automatically deletes preview sandboxes 30 days after update 29.0 reaches general availability, so sometime in early November 2026. A preview sandbox can't be updated to another version, so don't keep anything there you want to hold on to.
• Microsoft expected 29.0 to reach general availability in the first week of October and said on-premises details would be added at GA.

Caveats​

There are a few limits on how much to read into this:

• The roadmap is an estimate. The AI at Work roadmap says its dates and descriptions are subject to change, and entries can be removed once a feature ships, is cancelled or is postponed. "Launched" with an October GA month is a status label, not confirmation that the feature is in your production tenant today.
• Default bodies change interfaces somewhat. An interface used to be a pure contract with no behavior. Now it can carry behavior that implementers inherit, which brings the familiar problem of defaults that aren't quite right for a given implementer. Reviews will need to look at default bodies as carefully as at the signatures.
• The staging details aren't known yet. How long a method can stay pending, and how strictly AppSourceCop enforces the transition, will decide whether this actually eases upgrades or just moves the breaking change to a later release.

Bottom line​

This is one of the more useful items in the 2026 release wave 2 developer list, even if it gets less attention than the Copilot and MCP features. It addresses a real, documented constraint, the AS0066 ban on adding methods to published interfaces, with two pieces: default method bodies and a RequiredPending transition backed by the analyzers. Publishers get a way to evolve their interfaces, and implementers get notice before new methods become required. Test it in a 29.0 sandbox now, and wait for the GA documentation before you commit to any syntax.