Feature Flags on Team Level

[miscgithub]

Hi guys,

I'm currently integrating bullet train into a project of mine and came across the following challenge, on which I couldn't find a propper solution so far.

Problem:

I have users, which can be members of multiple teams. I want to be able to define feature flags on a per user level as well as on a per team level.

A team level flag may e.g. influence features of the team's dashboard. A team level flag should apply to all members of the team whenever they are active in the context of this particular team. The context is defined per session, that means a member can be with one team in a first session (e.g. browser window) while at the same time have a second session with another team. I assume that session management and contexts are handled at application level.

Considered Solutions (and why they don't seem to work):

1. Have a trait like "team" and define an according segment (similar to the approach in Segmentation #20) . Problem: As far as I understand traits are "user global", so the different sessions will interfer with each other and will overwrite their traits reciprocally.
2. Have multiple traits like "team-ID>" which shows if a user is active in a team. Problem: Cannot differentiate between different session contexts, the flag will apply to a user if he is at least in one matching team segment regardless of the actual team context.
3. Define the flag as a list of team IDs for which the feature is enabled, and match at application side agains current context. Problem: Leaks info about other users/teams and prevents propper A/B testing or gradual rollout.
4. Use two identities in parallel, one user identity and one team identity. Set the flags in the "right" identity and merge at application level. Problem: The JS client does not seem to support multiple instances.

Solution Ideas / Feature Request:

Maybe I'm missing a feasible solution here. In this case, please give a hint. Otherwise, the problem could be solved e.g. by one or both of the following features:

• Allow to define transient "per-session traits", which are used to match agains segments. This would allow to implement approach 1 from above.
• Allow multiple client instances in parallel, this would allow to implement approach 4 from above.

Keep up the great work and thanks for your support!

Best regards,
Michael

[dabeeeenster]

Interesting issue! I think there is a workaround that you could currently implement:

• Before calling getFlags for the session, set the relevant traits for that session
• Then call getFlags

How are you dealing with this within your application? Is it just via urls that define the team?

We've toyed with the idea of what we call "transient traits" that would allow you to specify traits that are not to be persisted to the DB. This would solve the problem I believe? It's a fair bit of work tho!

[miscgithub]

Thanks for the quick response and the proposed workaround!

Context information might come from a couple of sources. One is from the URL as you mention, other sources might e.g. be session cookies, or, as in my case, an upstream controller/router which provides a context object. Interestingly, you can have even more levels than just users and teams. If you think of an application like Trello, you can have feature flags on user level, on board level, on team level, or on enterprise level.

'Transient traits' as you describe them would most probably address these use cases, as long as their scope is limited to the current session/bullet train client instance. That would definitely be a powerful addition to bullet train's feature set!

Regarding the proposed workaround, I fell uncomfortable using a single global trait to control potentially parallel requests. As this would render the protocol between client and server statefull, I see quite a few of potential problems down the road, including concurrency issues and caching problems.

But your proposal raised an idea on getting approach 4 from above working: Using multiple identities for user and team. While I can have only one bullet train client instance, I can switch identities immediately before calling getFlags(), similar to what you describe above with traits. So I first get the flags for my team identity and then for my user identity and merge them at application level. This will preserve the statelessness property of the api protocol, as identity is managed locally by the client.

Downside is that I have to reimplement certain features of the client (like regular polling) and it increases the number of api request per client, but in an experimental implementation works quite well so far. Nevertheless, if I had a choice, transient traits would be the preferred solution :-)

[kyle-ssg]

Hey @miscgithub. Yeah this idea of transient / session based traits has been in our minds (and Backlog!) for quite a while now, similarly to your use-case our predicted ones are allowing for session based information such as browser type, location, device etc which could all form really useful segmentation.

Multiple instances seems like quite an overly complex concept, especially for frontend JS clients, however the ability to have a promise / async based call to set session traits (as well as having this in the initial identify) seems more appropriate.

I'd propose to keep this issue open whilst transient traits are worked on, and we can further discuss ideas here.

[miscgithub]

You are right, great additional use cases! I'm looking forward to this feature and I'm happy to help with any discusson, etc.

Thanks for your great work and support!

[kyle-ssg]

No problem, @miscgithub - thanks for being active and taking the effort to write here!

[freeman1995]

any update on that...?
i have the same problem basically

[dabeeeenster]

Not as of yet I'm afraid @freeman1995 - we are looking at transient traits based around headers (#171) which might be a solution here too.