Admin → Feature Flags → /feature-flags
A feature flag answers one question: is this available here? It is how a new module goes live for one branch, is watched, and is then extended — rather than appearing for everyone at once.
How flags resolve
Flags resolve through the same scope chain as settings, most specific first:
lease → unit → block → branch → organisation → platform default
A flag on for the organisation but off for one branch is off in that branch. That is the point.
Managing a flag
| Element | Purpose |
|---|---|
| New flag | Create a flag definition. |
| Module | Which part of the platform it governs. |
| Toggle | On or off at the selected scope. |
| Filters | Narrow the list by module and status. |
| Refresh | Re-read current state. |
Decide the scope
Almost always a branch. Organisation-wide is for capability everyone should have.
Turn it on
The module or behaviour becomes available to users with the right permission in that scope.
Tell the users
A module appearing without warning generates support calls, not adoption.
Watch before extending
Give it a full cycle in one branch before enabling it elsewhere.
Flags, permissions and jobs
Three different things can make a screen or behaviour unavailable. Check them in this order:
| Layer | Question | Where |
|---|---|---|
| Feature flag | Is this capability enabled for this scope? | Feature flags |
| Permission | Is this user allowed to use it? | Roles and permissions |
| Job switch | Is the background work behind it running? | Scheduled tasks |
A collections module that is flagged on, permitted, but whose sweep job is off will show an empty worklist forever — and none of the three layers is broken.
Flags and shadow mode
A flag makes a module available. It does not authorise it to act autonomously. Engines that touch money or reach residents also carry an enforcement mode setting that starts in shadow — staging actions for a human to confirm.
Enabling the flag and switching enforcement to autonomous are two separate decisions, taken at two different times, on purpose.
Rollout pattern
Enable in one branch
Ideally one with an engaged team who will report problems.
Run in shadow for a full cycle
Read what the engine would have done.
Enable action, still supervised
Humans confirm each action.
Extend to more branches
Once the first branch is boring.
Consider autonomy last
And per branch, never globally.
Convergence with settings
Feature flags and settings are converging onto a single configuration engine — same scope chain, same definition-and-override model. Behaviour does not change for you; where a flag lives may. See Settings.
Common problems
| Symptom | Cause |
|---|---|
| Module missing for one branch only | Flag off at that scope. |
| Module visible but empty | The job behind it is off, or nothing meets its criteria yet. |
| Some users see it, others do not | Permission, not the flag. |
| Enabled but nothing is sent | Shadow mode — actions are staged, not executed. |