Feature flags that only work when another flag is on

Someone ships new-checkout. A few weeks later express-payments lands, and it only works on the new page. The dependency is mentioned in Slack. It is not written on the flag.

A product manager then enables express-payments for a beta group that is still outside the new-checkout rollout. The new payment UI renders on the old page, which has nowhere to put it. Customers get a blank panel. Both flags are on for those users, so the dashboard does not look broken.

Two independent flags give you four combinations. The one you did not mean to support is still a state someone can turn on.

Use one flag with ordered variants

If the second behaviour only makes sense after the first, they are stages of the same feature. A single multivariate flag can say that:

• legacy: the old checkout.
• new: the new checkout, cards only.
• express: the new checkout plus express payments.

There is no variant for express payments on the old checkout, so that page cannot be configured. You test three paths.

If the flags have to stay separate

Sometimes the flags have different owners, or one of them will be removed months before the other. Read both in one function, and let callers use the result:

import Featureflow from 'featureflow-node-sdk';

const featureflow = new Featureflow.Client({
  apiKey: process.env.FEATUREFLOW_SERVER_KEY,
  withFeatures: [
    new Featureflow.Feature('new-checkout', 'off').build(),
    new Featureflow.Feature('express-payments', 'off').build(),
  ],
});

// Read both flags here. Callers use the mode.
function checkoutMode(user) {
  if (!featureflow.evaluate('new-checkout', user).isOn()) return 'legacy';
  return featureflow.evaluate('express-payments', user).isOn()
    ? 'express'
    : 'new';
}

Callers ask for the mode. They do not read the two flags themselves, so a later change cannot check one and forget the other. If express-payments is on and new-checkout is off, checkoutMode still returns legacy, and the page stays as it was. Put the requirement in the child flag's description so the person enabling it can see it.

Test the modes you can actually reach

With the decision in one function, the tests follow the modes that function returns. You do not need a separate test for every boolean pair. In Featureflow, a multivariate flag has the variants you define, and you set the failover when you register it. The audit log shows who changed which flag, which helps when you are reconstructing a bad combination. The docs walk through both.

Look for a pair where the second flag assumes the first is on. Fold them into one multivariate flag, or put both reads in one function, before that fourth combination shows up for a customer.

#FeatureFlags#FlagHygiene#Testing#ContinuousDelivery#DevOps