Feature Management and feature keys: shipping a change switched off

The Feature Management page lists optional features with a status per environment: Disabled, Enabled, or scheduled. Microsoft uses it for every change that alters behaviour (new experiences, new posting logic) and gives a window before it becomes mandatory. Your extension can register its own keys and ship a change dark: installed, invisible, switched on by the customer when they have tested it in the sandbox.

Registering a feature key

Your extension registers a key by inserting a record into the "Feature Key" table from the install codeunit (and once from upgrade, for existing installs), with a unique ID carrying your affix, a description, a learn-more URL, and the "Can Try" and "Is One Way" flags. The "Feature Management Facade" codeunit is then how code checks whether it is on.

local procedure RegisterFeatureKeys()
var
    FeatureKey: Record "Feature Key";
begin
    if FeatureKey.Get(NewPostingFeatureIdTok) then
        exit;
    FeatureKey.Init();
    FeatureKey.ID := NewPostingFeatureIdTok;                    // 'CONNewCourierPosting', locked label
    FeatureKey.Description := NewPostingFeatureDescTxt;
    FeatureKey."Learn More Link" := NewPostingLearnMoreUrlTok;
    FeatureKey."Can Try" := true;
    FeatureKey."Is One Way" := false;
    FeatureKey.Enabled := FeatureKey.Enabled::None;
    FeatureKey.Insert();
end;

Checking it

procedure IsNewPostingEnabled(): Boolean
var
    FeatureManagementFacade: Codeunit "Feature Management Facade";
begin
    exit(FeatureManagementFacade.IsEnabled(NewPostingFeatureIdTok));
end;

Branch on it at one place (the entry point of the feature), not in twenty. If the feature needs a data migration when switched on (a new table populated from an old one), implement the "Feature Data Update" interface and the facade runs your update, with a progress page, when the administrator enables it; that is what "Can Try" and the scheduled enablement are for.

One-way

"Is One Way" = true means it cannot be switched off once on (because the data has changed shape). Use it honestly; the administrator sees it as a warning before enabling.

The discipline

• Every key has an end date. Two releases with the switch, then the old path is removed, the key is removed, and the feature is simply how it works. A codebase with fifteen permanent switches is worse than one with none.
• Test both paths in the pipeline while the switch exists.
• Document the key in the release notes you give the customer, with what to test in the sandbox before enabling in production.
• Do not use it for configuration. "Does this customer use lot tracking on shipments" is a setup field. Feature keys are for rollout, not preferences.

Used this way, a feature key lets you deploy continuously (pipeline) while the business controls when behaviour changes, which is the only way the two coexist.

Related posts