The 6 Types of Feature Flags You’ll Meet at Optimizely: Permission

Tl;dr

🚩 How do we use Permissions Flags at Optimizely? Feature gating for plan types
🔒 Access Level? Monetization Engineers only
😬 Risk Level? High
👩‍💻 Tests? Manually Add/Remove Test Accounts
⏰ Lifetime? Permanent until feature deprecated

Permission feature flags are our feature enablement toggles which allow us to manage which customers are allowed to use certain features. By utilizing the audience targeting functionality of feature flags, we can create subscription tier plans where customers who pay for a higher tier can access more advanced features. We can also more easily audit and modify these subscription tiers.

How do we use Permission Feature Flags at Optimizely?

At Optimizely, our Monetization engineering team builds and runs our permission feature flags in partnership with our business systems teams. Once a development team has finished building out a new feature that is meant to be only in specific plans tiers, they hand off the code to the Monetization team which implements the permission feature flag. They build out a custom targeted audience for each tier and manage which customers belong in which audience groups.

Who is allowed to make changes to the Permission Feature Flag?

Permission feature flags have the highest access control across all feature flags at Optimizely. What that means is:

1. Only the Monetization team developers have edit privileges to these flags and are the only ones able to:
   1. Add customers to a flag
   2. Turn on or off the flag
   3. Change the rollout percentage of flag  
2. No one in the organization can access the Optimizely project that has permission feature flags except the Monetization team or select business partners. This ensures no one can disable the project, which would turn off all the flags in that project.
3. No one can emulate into Optimizely as a Monetization team engineer or business partner.

What is the risk level for using a Permission Feature Flag?

Permission feature flags start off as feature rollouts that are only targeted to an internal testing audience or beta customer. Before we are ready to gate our features, we have already tested these features in production and are highly confident they are working. The biggest risk we may have for a permission feature flag is if somehow the flag inadvertently fails (human error, system error) and the feature is no longer accessible by our customers. If this were to occur we would begin our incident outage protocols. 

How does Optimizely test its deployment of Permission Feature Flags?

Since permission flags are acting as gates for a tested feature, testing for permission feature flags revolve around ensuring the right customer is correctly bucketed rather than if the feature is working. This is usually handled by the business systems team as we add users into the permission flag. In general they perform this by picking a customer and emulating their experience on our product and validating that they are getting the correct set of features purchased.

When does Optimizely remove its Permission Feature Flags?

Permission feature flags are long term flags and are normally never removed. The only case where we remove the flag is if we make changes to our pricing tiers and need to redo our subscription model. 

This is the part of a series that will dive more into the different feature flag types we have here at Optimizely, as well as the engineering teams that implement them. See you next time as we dive in deeper on the Circuit Breaker feature flag type.

If you’re looking to get started with or scale feature flags, check out our free solution: Optimizely Rollouts! 

Are you using permission feature flags at your company? I’d love to hear about your experience! Twitter, LinkedIn