Roll out a feature with a flag

What this achieves

A feature flag decides whether a capability is switched on, without waiting for anything to be rebuilt or redeployed. It is how a new capability reaches a few workspaces first and everybody later.

Required role: Humavera platform staff.

Steps

Go to Platform → Feature Flags.
Select Create Flag.
Enter the Key, the Name, and a Description of what the flag controls.
Set Rollout % if the feature should reach a proportion of workspaces rather than all or none.
Select Save.
Use the switch in the Enabled column to turn the flag on or off.

What the list shows

Option	Description
Key	The flag’s identifier. It cannot be changed after the flag is created.
Name	The readable name.
Scope	Global or Tenant, depending on whether the flag applies platform-wide or to one workspace.
Enabled	The switch. Changing it takes effect at once.
Plans	Which plans the flag targets, where it targets any. Shown here rather than set here.
Rollout	The percentage of workspaces the flag reaches.
Overrides	How many named workspaces have an override on this flag.

The list can be searched by key or name, and filtered to Global only or Tenant-scoped only.

Per-workspace overrides

Editing a flag opens its Tenant overrides, where named workspaces are added one at a time. The rule that governs them is worth stating exactly, because it is asymmetric:

Option	Description
Flag globally disabled	Only the workspaces on the override list get the feature.
Flag globally enabled	Every workspace has it, and the override list makes no difference.

Example: a capability being trialled is left globally off, with two named workspaces added as overrides. Those two have it; nobody else does. When it is switched on globally, the list stops mattering.

Rolling out by percentage

Rollout % reaches a proportion of workspaces rather than a named list. A given workspace stays on the same side of that line as the percentage holds steady, so a customer does not see a feature appear and disappear between one day and the next.

Example: a flag at 10% reaches a tenth of workspaces consistently, which is enough to see how a change behaves without exposing everyone to it.

The key cannot be changed

A flag’s Key is fixed once created. The name and description can be edited afterwards; the key is what the product checks against, so it stays. Name it carefully the first time.

Deleting a flag

Deleting archives the flag rather than erasing the decision. Once it is gone, anything that checked it falls back to its own default value. Confirm you know what that default is before deleting a flag that is holding a capability off.

What happens next

A flag change is live from the moment it is saved. Customers are not told a flag moved: from inside a workspace, a capability that arrives this way appears without announcement. Where a change is significant enough that customers should hear about it, publish an announcement or a release note as well.