How should you behave in an environment where other developers/partners are working on different customizations? Maybe instead of creating one app, you should create two. Check the video for my take and a cool feature to the Simple Object Designer App:
In this video, Erik explores a practical architectural pattern for Business Central AL development: splitting a single app into two separate apps to avoid circular dependency issues. He demonstrates this concept using the Simple Object Designer, where he’s implemented automatic separation of “produce” and “consume” concerns into dual apps — and explains why this approach can benefit any AL developer working in multi-partner environments.
The Circular Dependency Problem
Erik begins by setting the stage with a common scenario that’s becoming increasingly prevalent in the Business Central ecosystem. As more tenants and customers have multiple parties supplying code, dependency conflicts arise more frequently.
Here’s the typical progression:
- You build App A — it works perfectly on its own.
- Another partner builds App B — also works perfectly on its own.
- The team building App B realizes they need to use a field from App A. No problem — App B takes a dependency on App A.
- Then the team building App A discovers they need a field from App B. Now App A needs a dependency on App B.
This creates a circular dependency: App A depends on App B, and App B depends on App A. Which one do you install first? You can only install an app if all its dependencies have been fulfilled. If neither can be installed without the other already being present, you’re stuck in a classic chicken-and-egg problem.
The Solution: Produce vs. Consume
Erik introduces a conceptual framework for thinking about this problem. When building an app, you’re doing two things:
- Producing — creating new artifacts (tables, fields, table extensions, etc.)
- Consuming — using existing artifacts (adding fields to pages, creating reports, building APIs, etc.)
By separating these two concerns into distinct apps, you can break the circular dependency chain. Here’s how it works:
- Split App A into App A1 (produce) and App A2 (consume).
- App A2 depends on App A1 — that’s straightforward.
- App B depends on App A1 (to use the fields that A1 produces).
- App A2 can now depend on both App A1 and App B.
The installation order becomes clear and achievable:
- Install App A1 (no dependencies)
- Install App B (depends on App A1, which is already installed)
- Install App A2 (depends on both App A1 and App B, both already installed)
No more circular dependencies — everything installs cleanly.
Categorizing AL Objects: Produce or Consume?
Erik walks through how various AL artifacts fall into the produce vs. consume categories:
Produce (App 1)
- New tables
- New fields (table extensions that add fields)
- Features and core table extensions
Consume (App 2)
- Adding calculated fields to reports and pages
- Marking mandatory fields
- Actions on pages
- Adding existing fields to pages and reports
- Exposing data as APIs
- Creating queries
- Page extensions, report extensions
The Corner Case
Erik acknowledges there’s an important edge case: FlowFields and lookup fields. These are technically “produced” fields (they’re real fields on the table extension), but they inherently have dependencies on other tables or fields that might live in another app. If a field in App A1 has a dependency on App B, then the circular dependency problem returns at the A1 level, and there’s no simple automated solution for that. Erik accepts this limitation, noting that it can’t be resolved in a simple, automated way.
Demo: Dual App Generation in Simple Object Designer
Erik demonstrates the upcoming feature in the Simple Object Designer. The process is remarkably simple from the user’s perspective:
- Open the app configuration and change from “single app” to “dual app”.
- Hit Publish.
Behind the scenes, the Simple Object Designer:
- Separates all objects into produce and consume categories.
- Compiles the first app (the produce app).
- Uses the first app as a symbol reference for the second app.
- Compiles the second app (the consume app) with a dependency on the first.
- Deploys the first app and waits for completion.
- Deploys the second app.
The download output is a ZIP file containing both app files. In Erik’s demo, the first app contained features and table extensions, while the second app contained APIs, page extensions, report extensions, and queries.
Deployment does take a bit longer since two apps need to be installed sequentially (each taking roughly a minute and a half to deploy to the cloud), but the process remains fully automated and simple from the user’s perspective.
Applying This Pattern to Your Own AL Development
While Erik built this feature specifically for the Simple Object Designer, he emphasizes that this architectural approach is broadly applicable to any AL developer:
- If you’re going into a customer environment where another developer or ISV is also producing customizations, consider splitting your app proactively.
- Start by asking yourself: “Am I producing or am I consuming?”
- Structure your solution as a multi-app setup from the beginning, rather than trying to untangle dependencies later.
This is especially relevant as Business Central environments become more complex, with multiple partners, ISVs, and freelancers all contributing apps to the same tenant.
Conclusion
Circular dependencies are a real and growing pain point in multi-app Business Central environments. By thinking about your AL objects in terms of produce (creating new schema and data structures) versus consume (using existing objects in pages, reports, APIs, and queries), you can split a single app into two and elegantly sidestep the circular dependency trap. The Simple Object Designer is making this automatic for its users, but the underlying principle is something every AL developer can apply to their own projects. Sometimes, two apps really are better than one.
