Application areas in Business Central

Business Central licenses come in tiers — Essential and Premium primarily. Different tiers unlock different feature sets. Application Areas is the mechanism BC uses to selectively show or hide UI controls based on which features are licensed and which scenarios are needed. It's quiet plumbing that most users don't notice, but understanding it matters for customisation and tenant configuration.

The application area concept. Every field and control in BC can be tagged with one or more application areas. When a user opens a page, BC checks:

• Which application areas the company has enabled.
• For each control, does any of its application areas match?
• If yes, render; if no, hide.

Out-of-box, BC standard control set ships tagged across application areas, allowing tenants to expose different feature sets.

Standard application areas.

• #Basic — fundamental operations.
• #Suite — broader suite functionality.
• #Finance — finance-specific.
• #FixedAssets — fixed asset management.
• #Manufacturing — production.
• #Service — service module.
• #Premium — features only available in Premium licence.
• #Advanced — advanced features.
• #All — always shown.

A control tagged #Manufacturing, #Premium shows only when both application areas are enabled.

Enabling application areas per company.

• Company Information page → Application Areas action.
• Checkboxes per application area.
• Saved per company.

Different companies in the same tenant can have different application areas; legal entities with different licence tiers stay separated.

The licence connection. The licence determines which application areas can be enabled. A company with an Essential licence cannot enable #Premium application areas — the system enforces.

Customisation via application areas.

• A custom field added by an extension can be tagged with an application area.
• Visible only in companies with that application area enabled.
• Useful for premium features within a partner extension.

Per-user override. Users can't override application areas — these are company-level. Personalization is the user-level mechanism for showing/hiding controls; application areas are operational policy.

Common use cases.

• Essential customer — sees core finance, sales, purchasing. Manufacturing controls hidden.
• Premium customer — sees everything including service and manufacturing.
• Multi-tenant partner — different customers with different enabled areas.

Adding a new application area.

controladdin MyControl extends MyTable
{
    field("MyField"; Code[20])
    {
        ApplicationArea = MyCustomArea;
        // ...
    }
}

Then enable MyCustomArea in Company Information.

For custom partner extensions adding their own application areas, the discipline lets the partner ship features that customers can selectively enable.

Hiding without application areas. Other mechanisms:

• Visibility property — code-driven show/hide.
• Permission sets — controls visible only to certain users.
• Personalization — user-level.

Application area is for license-tier or business-area-driven exposure. Visibility is for runtime logic. Permission is for security. Personalization is for user preference. The four mechanisms compose; understanding each prevents confusion.

Common pitfalls.

• Forgotten application area on new custom field. Field never appears.
• Application area set wrong. Field shows in all companies despite intent for premium-only.
• Conflicting application areas. Field with #Premium AND #Manufacturing; both must be enabled; user enabled only one; field hidden.
• Application areas vs Visibility confusion. Developers use Visibility when they should use ApplicationArea, or vice versa.

Migration considerations. When updating BC versions:

• Standard application area tags may change.
• Custom extension application areas should be tested against the new version.
• Some fields may appear or disappear due to platform changes.

Audit considerations. Application areas don't generate audit logs by themselves. Changes to enabled areas are tracked via change log if configured.

Per-tenant defaults. A new BC company gets default application areas based on the licence and the company creation wizard's choices. Reviewing and adjusting these post-creation is a setup step.

Strategic positioning. Application areas are a hidden but powerful feature for managing what users see. They reflect licence boundaries, business scope, and customisation strategy. For partner extensions, they enable tier-based product offerings. For multi-company tenants, they enable per-company scope. Most users never know they exist — and that's by design — but admins and developers benefit from understanding the model. Time spent learning it pays back when figuring out why a field doesn't appear or how to selectively expose features.