Business Central 29 ModuleInfo Adds Runtime Help, EULA and Privacy Manifest Links

What changes for AL developers​

Microsoft Learn describes ModuleInfo as an AL data type representing information about an application. Its existing reference lists accessors for metadata such as application version, dependencies, application ID, name, package ID, and publisher. The reference currently retrieved does not list the new help or legal-link properties.

The new capability therefore extends an established metadata mechanism rather than introducing a separate configuration store. Based on Microsoft’s feature description, an extension could use manifest-derived links when presenting its own support or application-information experience. That is a potential implementation benefit—not a promise that Business Central will automatically add new buttons or redesign an extension’s interface.

The distinction matters. Reading a link is not the same as displaying it, validating its destination, or ensuring the documentation behind it remains useful.

Availability: an October milestone, not a tenant guarantee​

Microsoft’s roadmap record for item 573354 lists the feature as Launched, with general availability dated October 2026. Its recorded scope is the web platform, General Availability release ring, and Worldwide (Standard Multi-Tenant) cloud instance.

That month-level entry should not be interpreted as proof that every environment had the capability on October 1, 2026. Microsoft explicitly describes roadmap dates as estimates and says roadmap information can change.

There is also a documentation boundary worth preserving: Microsoft Learn’s update 29.0 page still identifies itself as public-preview documentation for Business Central online sandbox environments, excluding production and on-premises environments from that preview scope. It places version 29.0 general availability in October 2026. Those notes corroborate the feature, but do not establish production availability in an individual tenant or support for on-premises deployments.

Help links already have distinct jobs​

One practical detail from Microsoft’s existing documentation helps explain how to approach the change: general app help and context-sensitive help are not interchangeable.

Microsoft Learn says the help property in app.json supplies Marketplace with a link describing the app or solution. By contrast, contextSensitiveHelpUrl identifies the documentation destination for the app’s functionality, while ContextSensitiveHelpPage maps individual pages or page-extension content to relevant articles.

That distinction gives publishers a useful preparation task: review whether each manifest destination serves its intended audience before exposing it in a custom interface. A product overview may be appropriate for “About this app,” but less helpful to someone trying to understand a specific field.

Localization also already has configuration support. Microsoft documents a {0} locale placeholder in contextSensitiveHelpUrl, together with supportedLocales. However, that existing routing documentation does not establish the exact locale-selection or fallback behavior of the new runtime properties. Developers should not assume the new accessors return either an untouched template or a fully resolved destination until the API contract confirms it.

What to verify before implementation​

The existing retrieval mechanism is documented: NavApp.GetCurrentModuleInfo obtains information about the application containing the currently running AL object. Microsoft also documents an optional Boolean result; capturing it allows code to distinguish successful retrieval from failure, whereas omitting it can produce a runtime error when retrieval fails. This explains how developers already obtain ModuleInfo, not how the new link properties behave.

Before adopting the addition, developers should verify:

• The exact property names, return types, and required runtime version.
• Whether the intended app context is supported.
• What happens when a manifest link is absent.
• How locale resolution and unsupported-language fallback work.
• Availability in the target environment before removing existing compatibility code.

The opportunity is straightforward: use manifest metadata as the authoritative location for application links, rather than keeping parallel URL constants. The sensible next step is equally straightforward—confirm the API contract and test the destinations. Less duplication is welcome; a confidently displayed wrong link is still a wrong link.