Should you use feature flags for entitlements? If you don’t have the option of a dedicated authentication framework, then the answer may be yes. If you do, it’s better to leave entitlement to the dedicated layer and focus your feature flags on leveraging that layer to power progressive delivery and experimentation.
An entitlement refers to the right to use a feature or product. It’s in this way that companies can control different experiences for their users. For example, a typical subscription model has different permission levels.
Let’s take Hulu, for example. With the first level of membership, you get to stream Hulu content with advertisements. In the second level of membership, you get to stream Hulu content without ads, and in the third level of membership, you get to stream without advertisements, and you get access to Live TV. For each tier of membership, you are entitled to different content and features. Now let’s understand how feature flags can streamline this process.
Leverage Your Existing Authentication Framework
Like the example above, if you are not using role-based access control (RBAC), you can use feature flags to create a simple entitlement system using allowlist functionality. However, when you use RBAC, like Okta, or Auth0, you can get information from them to make this process easier. All you do is inform your feature flag on what the various permissions are. Then, you can run experiments based on what permissions that user has simply by sending the list of entitlements in the optional attribute parameter in the Split SDK call. This is the perfect place to control entitlements, and we’ll talk about how feature flags can leverage that system for progressive delivery and experimentation in a moment.
Increase Revenue with Feature Flags as Entitlements
Using feature flags to manage entitlements can increase your company’s revenue. Let’s say you are a product manager for Hulu, and you want to test to see whether or not adding a promo for the ad-free live TV version to the first tier of membership with ads would make more people sign up for the third tier. You target those users based on that specific attribute in the feature flag. In the first week, you see that the people who saw the promo had a conversion rate much higher than the people who did not see it. You can now confidently increase the allocated traffic for that group, but only for the people in that first tier. In this way, using feature flags for entitlements can increase your revenue.
You can also use feature flags for entitlements to target specific customers who you want to give access to features before they are released to everyone. For example, let’s say you are a salesperson at a fintech startup, and you are trying to get one of your customers to upgrade from Level 1 membership to Level 2 membership to increase sales. You could add that customer for a short time into the feature flag that manages Level 2 and see if they like it. If they do, they will continue in the sales process and move to Level 2 membership.
Add an Abstraction to Both Systems
Teams will often run into challenges where the feature flag system doesn’t have all the necessary capabilities for entitlements. To avoid all your code having to think about two types of decisions, you can keep a common abstraction over your feature flag system and entitlements system. The two decisions are: Is the flag on, and is the user entitled to that thing. The decision point in the code looks the same (should I show feature X to this user or not), but the reasons behind that decision might vary. It could be turned off because there’s a feature flag that’s off for that user, or it could be turned off because the entitlements system says that the user isn’t allowed to access that feature.
Manage Feature Flags as Entitlements
The role of the feature flag manager can vary between companies. In many cases, the product manager is in charge of the feature flag, while the developers simply add them to their code. The best practice here is to distinguish the role of each person in the feature flagging process. For example, when a developer starts working on a feature, she can create the feature flag and add all the corresponding code. Once she finishes, she can add the QA team to the flag’s allowlist to start testing. Once QA signs off, they can alert the product manager, who will coordinate the release. Having specific roles and responsibilities assigned ahead of time is especially crucial with entitlements. As entitlements are more of a feature management role, the person who manages this should be on the Customer Success or Sales team.
Just as it’s crucial to have the correct roles in place, you also need the ability to update and modify entitlements easily. What happens when a customer wants to go from one tier of membership to another? It should be intuitive in your feature flag management system to add and remove users or segments of users in different tiers so that your customer success and sales teams can manage the process seamlessly.
Employ Your Dedicated Entitlement System To Drive Progressive Delivery and Experimentation With Feature Flags
Dedicated entitlement systems tackle these use cases well. Since they are typically tightly coupled to authentication systems, they provide a well-defined and secure way to add and remove users and permissions from a single place. By definition, dedicated entitlement systems know what your users should and should not have access to or whether they are of a specific “tier” in the Hulu example. We can easily use that information in targeting rules for progressive delivery experiments.
Feature flags can also use more than just a user ID to drive targeting. Anything your app “knows” about a user can be used to target exposure of a feature. With Split, you share this enhanced context about a user by passing an attribute map in your getTreatment calls. So, for example, if we passed something the entitlement system knew about the user, like (plan_type, growth), we could choose to roll out a new feature to just a small percentage of the growth plan type users with a rule like this:
Learn More About Feature Flags
Feature flags have many benefits: optimizing releases, allowing teams to test in production, acting as a kill switch, and acting as an entitlement system. When all of these processes work in parallel, you can get a lot more bang for your buck! And there are so many more use cases for feature flags. You can learn more from these resources:
- Build a Continuous Deployment Pipeline in Java with Travis CI
- A Quick Guide to Implementing Feature Flags with Spring Boot
- The Benefits of Feature Flags in Software Development
- Feature Flag Maintenance
- Pros and Cons of Canary Release and Feature Flags in Continuous Delivery
To stay up to date on all things testing in production and feature flags, follow us on Twitter @splitsoftware, and subscribe to our YouTube channel!
Get Split Certified
Split Arcade includes product explainer videos, clickable product tutorials, manipulatable code examples, and interactive challenges.
Switch It On With Split
Split gives product development teams the confidence to release features that matter faster. It’s the only feature management and experimentation platform that automatically attributes data-driven insight to every feature that’s released—all while enabling astoundingly easy deployment, profound risk reduction, and better visibility across teams. Split offers more than a platform: It offers partnership. By sticking with customers every step of the way, Split illuminates the path toward continuous improvement and timely innovation. Switch on a free account today, schedule a demo to learn more, or contact us for further questions and support.