In the previous post in this series, we mentioned how important it is to adhere to naming conventions to keep track of your flags, such as who created them and for what purpose.
We also mentioned that in a worst case scenario without such conventions, someone could accidentally trigger the wrong flag inciting disruptions within your system.
This brings us to why it’s also essential to manage and control who has access to the flags in your system. Without access control, you might also risk someone switching on a faulty feature and going live to your user base.
Consequently, access control should be used to manage the level of control people across your organization have and restrict usage if necessary.
The general rule of thumb is to only give users the kind of access they require to do their job, not more and not less.
Let’s look at a practical example…
AB Tasty, for example, offers a feature flagging functionality that is designed to be used by product and marketing teams as well as developers while offering fine control over user access.
As you can see in the image above, there are different categories of access under ‘Role’ in the AB Tasty dashboard. There are 4 categories overall, which are divided as follows:
- SuperAdmin- this is the category with the highest access privileges. The SuperAdmin can do anything from creating a project to toggling on/off a use case as well as access reporting.
- Admin- the Admin can do almost anything a SuperAdmin can except create, delete or rename a project
- User
- Creator
- Viewer
User, Creator and Viewer have varying but lower levels of access with Viewer having the lowest level of access.
It’s essential that as your use-cases grow and as you go further along the feature flag journey, you are able to manage access for users at a detailed level.
This is also useful when you’ve scheduled regular flag clean-ups to avoid technical debt. By implementing access control, you’ll minimize the risk of having someone on your team accidentally delete a permanent flag. Similarly, it allows teams to track short-lived flags they created so that they can delete them from your system to avoid accumulation of technical debt.
This way, each flag owner would be responsible for assessing the flag they own and keep tabs on it by grouping flags by owner instead of allocating the task of auditing the entire set of flags in your system at random.
Determining who gets access to what
As you’ve seen so far, different teams within your organization could and should have different levels of visibility and access to flags.
Once you’ve decided who gets access to which flags, you’ll need to consider how to control access.
Are technical teams the only ones allowed to make changes or will other teams such as your product and marketing teams get access to flags too? If so, you might need a sophisticated control panel to help them make changes.
Opting for feature flags as a service from a third party will make this process easier rather than building your own system as such services would provide you with a rich UI control panel without costing you too much time and money.
In contrast, building your own advanced feature flag service could drain your resources, especially as your use cases become more advanced and as more of your teams start using this service simultaneously.
Read more about whether you’re better off building or buying a feature flagging management system.
Audit logs
One way to track changes and control access to feature flags is by constructing an audit log. Such a log would help you keep track of all changes being made to each feature flag, such as who made the changes and when.
It allows for complete transparency, giving full visibility over the implementation of any feature flag changes in your system.
Because flag configuration carries risk, having an audit trail of change is crucial, especially when flags are being used in a highly regulated environment such as in finance or healthcare.
Thus, this makes the process more secure when you restrict access to the number of people allowed to make changes to sensitive flags.
Why does this matter?
At this point, you may be wondering why you should even be considering giving all your teams, especially your non-technical teams access to feature flags.
While your team of developers are the ones who create these flags, it is usually your marketing or product teams who will decide when to release a feature and for what purpose. They are the ones that are working closely with your customers and know their needs and preferences.
It is usually the case that your marketing team is the one forming these experiments in the first place to test out a new idea and this team would know who are the most relevant users to test on.
Therefore, the marketing team would often be the one who’s handling the experimental toggles, for example, to run A/B tests.
Meanwhile, operational toggles such as a kill switch are usually handled by the operations team.
When you have a clear-cut UI panel, you are restricting what those teams can do so each team focuses on managing the flags they’re actually responsible for without allowing any room for error.
A management system should allow you to keep track of your toggles, who created them and who can flip them on and off safely.
Conclusion
It’s important that you ensure you have full visibility over the flags in your system and that everyone across your teams know their level of responsibility when it comes to implementing feature flags.
Most sophisticated feature management solutions provide role-based access controls as well as an audit log for flags and contributors for increased transparency over your flags.
With such solutions, you would have an easy to use interface that allows you to expand feature management beyond your development team in a safe and controlled manner.
