Business Central feature management

Microsoft ships many Business Central features as opt-in capabilities behind a runtime toggle, rather than enabling them automatically for all tenants. The Feature Management page is the administrator's control panel for these toggles. Understanding it is essential for managing the change pace inside each release wave.

The model. Each feature in Microsoft's Feature Management catalogue has a status:

• Preview — available in the platform but disabled by default. Administrators can enable per environment for testing. Behaviour may still change before general availability.
• Generally Available, opt-in — the feature is stable, but not auto-enabled. The administrator chooses when to turn it on. Many features stay in this state for one or two waves before becoming mandatory.
• Generally Available, default on — the feature is enabled automatically; it can still be temporarily disabled in some cases for backward compatibility.
• Mandatory — the feature is on and cannot be disabled. Eventually every default-on feature becomes mandatory.

Why opt-in. Microsoft uses opt-in features to:

• Ship new functionality without surprising customers mid-quarter.
• Let customers test in sandbox before enabling production.
• Catch breaking-change risk early — admins who enable preview features feed back to Microsoft on problems.
• Allow partners to test extension compatibility against new platform features.

The Feature Management page. A grid showing every feature, its status, a description, a link to the documentation, and the toggle. The administrator enables or disables per environment. Changes can take effect immediately or require a session restart.

Examples of opt-in features. Recent releases have used Feature Management for:

• New AL platform capabilities (e.g. new query language constructs, new event signatures).
• New UI patterns (e.g. modernised list pages, new filter experiences).
• Application-level changes (e.g. new copilot capabilities, new bank reconciliation logic).
• Integration changes (e.g. new connector versions, new API behaviour).

Sandbox-first. The discipline is: enable previewing features in sandbox first, run regression tests, confirm extensions still work, then enable in production. Tenants that flip features in production without sandbox validation occasionally find that an extension breaks or a workflow behaves differently — the kind of incident that erodes user trust.

Telemetry. Application Insights telemetry records feature enable/disable events with the user, environment, and timestamp. Useful audit when investigating "why is this behaving differently than last week".

Per-environment vs per-company. Most features toggle per environment (affecting all companies inside it). A small number toggle per company; the Feature Management page makes it clear which.

The progression. A feature typically lifecycles:

1. Wave N — released as Preview opt-in.
2. Wave N+1 — moved to Generally Available opt-in.
3. Wave N+2 — moved to default-on, with option to disable.
4. Wave N+3 or N+4 — mandatory; toggle removed.

Customers who never opt-in get features automatically when they become default-on — usually well-tested by then. Customers who opt-in early get features sooner and help shape the rollout.

Best practice. Review Feature Management every release wave alongside the published Release Plan. Enable previews for features you care about; leave the rest alone.