Business Central 29 Lets Developers Find Objects Installed in Connected Environments

What Microsoft announced​

The roadmap entry is ID 573339, titled "Dynamics 365 Business Central: Development - Discover objects in connected Business Central environments." It describes searching the objects installed in a connected Business Central environment. The results include metadata about the app that owns each object, which is what you need to add the right dependency and download the right symbols.

Microsoft's business case is short: developers and coding agents can find AL objects in the target environment even when the matching symbols aren't in the workspace yet. In the roadmap's words, that "reduces failed searches and helps agents add the correct app dependency before generating code that uses an object."

The listing's metadata:

One caveat: the roadmap itself warns that its dates and descriptions are estimates and can change. The status and scope above come from the roadmap listing. We couldn't confirm the details of this entry on the live roadmap page separately.

Section summary: Business Central development tooling can now search what is actually installed in a connected environment, not just what your local symbols cover, and each result names the app that owns the object.

Where it fits in the 2026 release wave 2 picture​

The feature doesn't stand alone. Tech Sphere Dynamics reviewed the Business Central 29.0 preview and grouped a cluster of agent-oriented AL changes together. Its list included running data queries through an MCP Server, dynamic workspace configuration for AL MCP, discovery of the objects installed in a connected environment, free AL object ID allocation performed by agents, plus an AL Language Server that no longer depends on Visual Studio Code and command-line test execution. The publication summed up what agents need as programmatic access to context, environment discovery, and tools that work without a graphical interface.

That fits. A human developer can switch to the browser, open Extension Management and work out which app owns an object. A coding agent working through MCP can't do that. If its symbol search fails, it may guess at a dependency or simply write code against an object it can't resolve. Environment-side discovery gives the agent a source of truth before it writes code it can't back up.

Why existing search misses these objects​

To see why this is useful and not just a renamed feature, look at how today's tools define their scope.

Microsoft's al_symbolsearch tool, documented for AL Language extension 17.0 and later in both Visual Studio Code and the AL MCP Server, searches AL symbols—objects such as tables, codeunits, pages, reports, enumerations, and interfaces, as well as their members such as fields, methods, keys, actions, and triggers—across the active project and all referenced dependencies. The key limit: results come from the AL Language Server, which ensures that the search is workspace-aware and reflects the current compilation state.

Its scope filter accepts project, dependencies or all. Here "all" means your project plus the packages it references, not every app installed in the tenant. If an app isn't in app.json and its symbols aren't in .alpackages, local search can't see it.

Earlier improvements stayed inside the same boundary. In the 2025 release wave 1, Microsoft made it possible to search AL objects from downloaded symbol packages from within Visual Studio Code. That was helpful, but the important word is downloaded. AL Explorer is similar. Microsoft's documentation says it gives an overview of all objects in a given app scope, such as a workspace or a selected project, with object-name search and grouping by type. It's a strong exploration tool, but its documentation doesn't say it can search apps installed in a tenant whose symbols you don't have.

The new roadmap feature goes one step further: it searches what's installed in the environment, whatever your workspace happens to hold.

Section summary: Today's tools search the project and the dependencies it already references. This feature searches the connected environment, which can be a much larger set.

A practical workflow (with honest caveats)​

The roadmap doesn't name a command, a tool, a menu label or a parameter for the new search. So we won't invent one. Here's how it slots into the symbol workflow Microsoft already documents:

1. Discover the object in the connected environment. Note the owning app the search reports. The roadmap says this metadata is included, but doesn't list the exact fields.
2. Check app.json. Add the dependency for the owning app if it isn't already there. The roadmap says discovery helps you add the right dependency. It doesn't say the feature edits app.json for you.
3. Download symbols. Microsoft's documentation recommends running al_downloadsymbols before building or compiling if you encounter "symbol not found" errors, if you have added new dependencies to app.json, or if you want to refresh symbols to pick up updates from a connected Business Central environment. In Visual Studio Code, connection details are read from the active launch.json configuration. Packages land in the project's .alpackages folder, and the compiler picks them up automatically.
4. Build and check diagnostics. Microsoft's agent-tools overview describes the documented build-and-validate loop as downloading symbols, running al_build (or al_compile in AL MCP), then calling al_getdiagnostics.
5. Confirm success. You're done when the reference resolves cleanly and al_symbolsearch with the default scope now returns the object.

On authentication, the agent-tools overview says that when a tool needs a Business Central cloud environment, it starts a browser-based Microsoft Entra ID sign-in, and AL MCP users can call al_auth_login first. That describes today's tools. It's a reasonable expectation for the new search, but not a confirmed requirement.

Common failure points to watch​

These come from the documented symbol tooling, not from tests of the new feature:

• Wrong environment in launch.json. Whatever is configured there is the environment you'll download symbols from. If it points at a different sandbox than the one you searched, you can get mismatched symbols.
• Authentication errors. For AL MCP, Microsoft suggests running al_auth_login and retrying, or setting noCache: true to force a fresh sign-in.
• Stale caches. In AL MCP, force: true re-downloads every symbol package, even ones already cached.
• Offline or CI scenarios. globalSourcesOnly downloads platform and base application symbols from Microsoft's NuGet feeds and AppSource without connecting to a server. dvlprlife.com notes that the related command downloads the application packages your project depends on from Microsoft's public NuGet feed — matched to whatever version you've set in the application tag of your app.json. That's handy when no tenant is reachable, but it can't tell you what a particular customer's tenant has installed. That's exactly the gap environment discovery fills.

What we still don't know​

The roadmap leaves several practical questions open:

• The minimum Business Central version and AL Language extension version.
• Whether it appears in Visual Studio Code, AL MCP, the AL LSP server or all of them. The roadmap lists only "Web" as the platform.
• Required permissions, available search filters and exactly which metadata fields come back.
• Support for on-premises deployments or cloud instances other than Worldwide multi-tenant.
• Whether discovery ever downloads symbols or edits app.json automatically.

Partners with large AppSource or per-tenant extension estates will want answers, particularly on permissions. A tool that lists everything installed in a production tenant is a convenience, and an inventory that admins should know is reachable.

The bottom line​

This is a small roadmap entry that fixes a real, everyday annoyance. For human developers it shortens the hunt for which app owns an object. For coding agents it matters more: it's the difference between finding the right dependency and confidently writing a reference that won't resolve. Watch the AL documentation for the actual tool name and requirements before you build team workflows around it. Until then, the documented pattern of discovering, adding the dependency, downloading symbols and compiling is the safe way to work.