Feature flags for MENA SaaS: a release contract
Design stable tenant cohorts, explicit outage behaviour and tested rollback for bilingual SaaS deployments in Saudi Arabia and the UAE.
A feature flag is turned off in the dashboard, but one worker keeps using the new behaviour. Another process has just restarted and takes a different path. Both are following their local configuration.
For a SaaS product serving Saudi and UAE customers, a gradual release needs more than a percentage slider. The team must decide who moves together, which deployment receives the change and what happens when configuration updates stop arriving.
This guide proposes a release contract for a bilingual B2B approval workflow. It is an engineering design, not a benchmark or a claim that either country requires a particular flag platform. The aim is to make exposure and rollback predictable without confusing them with access control.
Cover: original SultanByte artwork showing a controlled release to separate Saudi and UAE deployment cohorts.
Keep permission separate from exposure
Microsoft's feature-flag guidance distinguishes deploying code from exposing it. A flag can leave a new path dormant while the same application build serves existing customers.
That does not make a flag an authorization system. OWASP recommends checking permissions on every request and warns against relying on client-side checks. Hiding an approval button must not allow someone to call its endpoint directly.
For this design, the server first verifies the actor, tenant and permitted operation. It then decides whether that authorized operation uses the established workflow or the new one. Both paths enforce the same object-level permissions. A missing or malformed flag context must never turn a denied operation into an allowed one.
Use a distinct entitlement check if the feature belongs to a paid plan. Commercial eligibility, security permission and release exposure can all influence the result, but each needs its own owner and failure policy. A release operator should not accidentally grant access to customer records by adding an account to a pilot.
Choose the unit that moves together
For a shared approval workflow, this proposed rollout assigns whole tenants rather than individual employees. Otherwise, the person submitting a request might see a new state that the approver's version cannot interpret.
User-level assignment can still suit an isolated presentation experiment. The decision depends on which people and services share the resulting state. Record that unit before configuring the rollout.
Unleash documents deterministic stickiness based on a context field and a group identifier. Its default selection uses a user ID, then a session ID; when neither exists, assignment is random and stickiness is not guaranteed. Custom stickiness has its own configuration and product availability conditions. Do not assume an SDK automatically uses your tenant identifier.
Use an opaque, stable identifier for the chosen unit. Renaming a company, changing language or refreshing a session should not silently change its release cohort. Verify the provider's handling of missing identifiers and deliberate changes to the grouping key.
Also distinguish a percentage of tenants from a percentage of traffic. One busy tenant may dominate requests. A small tenant cohort can still generate substantial workload, so exposure counts and operational load need separate measurements. A rollout percentage is not a capacity guarantee.
Build context from trusted records
OpenFeature's evaluation-context specification defines a targeting key and custom fields. It also defines context-merging precedence, with invocation context and before hooks able to overwrite values supplied at lower levels. That flexibility deserves a trust review.
For the approval service, construct the following record on the server:
The verified tenant identifier, used as the cohort subject.
The deployment identifier from service configuration.
The tenant's approved pilot status from a controlled record.
The requested interface locale, validated against supported values.
Treat these as different facts. Arabic does not mean Saudi Arabia, English does not mean the UAE, and a customer-selected country field does not authorize a deployment change. If the product operates separate Saudi and UAE environments, configure and test their rollout boundaries independently.
Do not merge arbitrary request JSON over this record. Review hooks and wrappers that can replace trusted fields. In a concurrent server, avoid changing a global user or tenant context for each request; use the SDK's appropriate request-scoped mechanism and test overlapping requests for different tenants.
SultanByte's tenant-isolation review covers the underlying access boundary. A flag evaluator consumes that verified context; it should not invent it.
Read the rule logic before widening the pilot
A second targeting rule can broaden exposure rather than narrow it. Unleash's activation-strategy documentation says multiple strategies combine with OR, while constraints within a strategy combine with AND.
In that model, adding a separate “UAE deployment” strategy alongside a gradual rollout does not necessarily mean “gradual rollout only in the UAE.” Either strategy can enable the flag. Put required restrictions into the appropriate combined condition and verify the actual evaluation results.
That example is specific to Unleash. Other products have their own rule ordering, fallthrough and prerequisite semantics. Preserve test fixtures when translating a policy between tools rather than assuming similar dashboard labels imply identical behaviour.
For this pilot, require explicit results for an eligible tenant in each deployment, an ineligible tenant, a missing tenant and a tenant whose pilot status has been removed. Include a language switch within the same tenant. Review the complete rule change, not only the edited percentage.
Original infographic: SultanByte. Proposed engineering framework informed by OWASP, OpenFeature, Unleash and LaunchDarkly documentation, October 2026. These are design checks, not measured rollout results.
An outage has more than one fallback
Do not document failure behaviour as simply “the flag defaults to false.” The running process may already have a usable ruleset.
LaunchDarkly's network-failure guidance distinguishes initialized SDK instances that retain their last known flag data from new instances that cannot initialize and use configured fallback values. Persistent stores and other configurations can change the startup path. Confirm the behaviour of the exact SDK and configuration you deploy.
For the proposed approval workflow, define separate outcomes:
On a healthy evaluation, use the selected workflow version.
On a cold start without usable configuration, keep new operations on the established path.
On loss of updates after initialization, apply the documented stale-configuration policy rather than assuming the cold-start fallback runs.
On invalid evaluation context, reject or safely defer the operation according to its contract; do not guess a tenant.
A cached “enabled” decision may survive a control-plane outage. Therefore, a dashboard toggle is not proof that every worker has stopped admitting new work. If the business needs a bounded emergency stop, design an admission control whose freshness and failure behaviour meet that requirement, then test it under disconnection. Do not claim the flag service provides that bound without evidence.
Record the time of the last successful configuration synchronization where the implementation exposes it. A recent evaluation timestamp alone does not prove the rules are recent. Monitor disconnected instances and cold-start defaults separately so a fleet does not quietly split into incompatible behaviours.
Keep workflow decisions stable after acceptance
Choose a workflow version when an operation is accepted and persist it with the operation. In this design, a queued approval continues under its recorded compatible version rather than reevaluating a mutable release flag at every step.
Keep authorization and emergency safety checks current. Persisting a workflow version must not preserve a user's revoked permission. The worker needs to distinguish “which implementation handles this record?” from “may this action proceed now?”
Turning off the rollout stops new admissions to the new path according to the tested propagation policy. It does not reverse emails already sent, approved records or database writes. Define how in-flight operations finish, pause or require intervention.
Both old and new implementations must understand the data they can encounter during the transition. Test rollback after the new path has written real-shaped test records, not only before any writes occur. Microsoft also notes that retained alternate code paths need continued testing and maintenance. Remove an obsolete release flag only after the workflow and recovery obligations no longer depend on it.
Review where evaluation data goes
A regional application server does not establish the location of all flag-related processing. LaunchDarkly's SDK comparison distinguishes server-side local ruleset evaluation from client-side evaluation through its services. It also warns never to expose a server-side SDK key in a browser or mobile application.
The same documentation makes an important privacy distinction: server-side private attributes are not sent back to LaunchDarkly, while client-side private attributes are still sent for evaluation but excluded from events and storage as described there. “Private” does not mean the same network behaviour in both SDK types.
For each Saudi or UAE deployment, inventory configuration delivery, evaluation requests, events, persistent stores and administrative access. Send only context needed by the rules. Avoid names, email addresses and document content when opaque cohort identifiers and approved attributes suffice. An opaque identifier can still be linkable; do not describe it as anonymous by default.
Have the customer's specialists review the actual processing arrangement where contractual or regulatory obligations apply. This is practical engineering information, not legal advice, and the guide does not assert identical requirements across the two countries.
Approve a release with a failure record
Start with internal test tenants, then a deliberately selected customer pilot. Before widening exposure, require a short record covering both deployments and both interface languages:
Verify permission denial even when the release flag is enabled and the endpoint is called directly.
Confirm stable tenant assignment across sessions, replicas and language changes.
Disconnect configuration delivery on a warm instance; repeat with a cold instance. Inspect the actual decisions.
Disable the rollout while operations are queued and executing. Check new admissions separately from work already accepted.
Run the established path against records produced by the new path and exercise the agreed recovery procedure.
Inspect outgoing evaluation and telemetry traffic for unexpected identifiers or customer data.
These are proposed acceptance tests, not reported results. Record the application build, SDK version, flag configuration and interruption used so another engineer can repeat them.
Product should approve the pilot cohort and customer-facing behaviour. Engineering should approve compatibility and recovery. The release owner should retain the rule change and observed health signals before expanding exposure. A higher percentage is justified by evidence that the selected customers can complete the workflow and that the team can contain a failure, not merely by an absence of complaints.
