Flag types
Each flag carries one of three types so the dashboard can group and report on them appropriately.
For shipping new functionality. Typically short-lived — created when you start writing the feature, deleted once the rollout is complete and the old code path is removed.
For A/B / multi-variant tests. Lives on the Performance tab where you can record conversion events and read p-values + uplift per variant.
Long-lived emergency switches around third-party integrations or expensive features. Always default to "on"; flip to "off" during incidents.
How evaluation works
When your service calls POST /flags/{key} with your x-management-key, Maxlona confirms your organization's account is in good standing, checks for an active kill switch, then matches your request against the flag's targeting rules for that environment to decide a variant. Assignment is deterministic per user, so the same person keeps seeing the same result as you adjust a rollout, and exposures are recorded for A/B analysis.
Evaluation is fast enough to call on every request without adding noticeable latency. Add ?explain=true to the URL to get back a detailed reason object explaining which rule fired and why.
Built-in JSON tester
Sidebar → Test → Tester. Paste a flag key and a user JSON payload, hit Evaluate, and you'll see the variant, the reason ("rule-2 matched on attributes.plan == 'pro'"), and the full evaluation trace. The fastest way to debug "why didn't user X see the new feature?" without waiting for a real request to hit your service.
Automate the release journey
Feature Flag Automation turns a release plan into controlled steps. Instead of asking someone to remember when to promote a configuration, increase a rollout, expire a temporary feature, or retire a completed flag, describe the journey once and let Maxlona execute each step when its trigger is ready.
Common use cases
Schedule a future start at 10%, wait between checkpoints, then move through 25%, 50%, and 100%. Each increase can target one environment without changing another.
Copy a known configuration from Dev to Test, UAT, or Production, with manual approval before a sensitive promotion.
Advance after a number of evaluations or unique users rather than a fixed wait. This is useful when traffic varies throughout the day.
Apply targeting for a country, region, state, or another context property, then expand accepted values as the launch progresses.
Turn a flag on at a chosen time and disable it after a duration. An expiration action can place a firm end date on temporary behavior.
Detect when a fully released flag becomes stale, notify the team, require approval, and archive it after dependency checks pass.
Capabilities
Every stage answers five questions: when it runs, where it applies, who receives the change, what changes, and which safety gates must pass.
| Capability | Available options |
|---|---|
| Triggers | Specific date and time, duration after the previous step, evaluation count, unique-user count, lifecycle-state change, or manual approval. |
| Actions | Promote configuration, enable or disable, set rollout percentage, update audience targeting, set expiration, send a notification, or archive the flag. |
| Audience | Everyone, or requests matching an exact context property and one or more accepted values. |
| Safety | Administrator approval, dependency-impact acknowledgement, configuration-version checks, environment checks, and an optional telemetry deadline. |
Build and manage a plan
- 1Start a new draft. Choose Scheduled activation, Progressive rollout, Environment promotion, Consumption based, Regional launch, Temporary flag, Release retirement, or Custom plan. Templates are starting points and never overwrite saved plans.
- 2Edit the stages. Choose environments deliberately, add required promotions, adjust triggers and atomic actions, and use environment lanes to review the journey.
- 3Save and validate. Validation identifies missing configurations, contradictory actions, invalid variants, unsafe archive placement, and other problems before execution.
- 4Review and activate. Activation records expected configuration versions. The worker checks them before every step and suspends the plan if configuration changed unexpectedly.
- 5Operate safely. Suspend an active plan before editing, resume after validation, cancel future execution, duplicate it as a fresh draft, or permanently delete it. Deletion retains an audit record.
Conflicts and lifecycle protection
Drafts may overlap so teams can explore alternatives, and the planner warns when they share environments. Structurally identical plans cannot be saved. Only active plans lock the environments they read or change. A suspended plan is retained but inactive, so it does not reserve flag or environment resources; if it is resumed later, conflicts are checked again against plans active at that time. Non-overlapping active plans can run together.
Promotion locks its source and destination. Consumption triggers lock their measurement environment. Flag-wide lifecycle, expiration, and archive work conflicts with every other runnable plan for that flag.
Automation never overrides a terminal state. If a flag becomes Stale, Archived, or is deleted, its automation stops and cannot reactivate or promote the flag. An environment or flag referenced by runnable automation cannot be removed until the dependent plan completes or is removed. A promotion never adds an environment the flag doesn't use: validation blocks it before activation, and if the flag's environments change afterwards the plan is suspended with that reason. Likewise, an environment an active or suspended plan uses can't be removed from the flag.
The Lifecycle & automation widget lists active and suspended plans, step progress, affected environments, the next scheduled action or suspension reason, and counts for draft, completed, and cancelled plans.