How to make use of the ownership and permission model
Over the last few months we incrementally released many new features related to teams, ownership & collaboration aimed at improving how teams are experimenting and collaborating with each other. In this document we will discuss those changes and how you can start making use of them.
Team structure
The first building block was to make it possible to map your internal team structure in ABsmartly so your teams can be structured just like they are in your organisation.
If you have not done so yet, we encourage you to go to /settings/teams and start building a team structure which aligns with the way you are structured and operating (or any other which makes most sense from the organizational point of view). Unless you start building your team hierarchy in ABsmartly you won't be able to start making use of the new features described below.
Team ownership
Until now, the ownership of anything created on the ABsmartly platform was set at the individual user level (usually the person who created the item).
While this is often fine, in many cases it is preferable for assets like Experiment or Metrics to be owned by a team and not by an individual.
Team level ownership is more resilient to changes and it makes it easier to manage and share assets at scale.
Because of this we introduced team level ownership for Experiments, Features, Templates, Goals & Metrics.
Other assets like Applications, Tracking Unit, etc which are platform level settings remain unchanged.
For backward compatibility, existing assets will retain their current individual owners but it won't be possible to add new ones.
While Team Ownership is the new default and preferred way of assigning ownership for Experiments, Features, Templates, Goals & Metrics, it is possible to re-enable user level ownership in the platform settings (/settings/platform).
To get the most of the new model we encourage you to move the ownership of your existing Experiments, Features, Templates, Goals & Metrics to the most relevant team in your organisation. To do that, just edit assets that you currently own and re-assign ownership to the correct team. Make sure that you are a member of that team if you want to retain your access to that asset.
Team membership & roles
Together with the new team structure, you can now also assign members to those teams. By default all platform users are members of the Global Team (feel free to rename it so it matches your company name) which represents your entire organisation but you can now also add them to their actual team in the team hierarchy.
When adding a new member to a team, it is also possible to assign this user an optional role in that team. The role that a member has in a team will define how this person can interact with the assets owned by that team. Assets here are Experiments, Features, Templates, Goals & Metrics.
Possible team roles are :
- Team viewer: The member will be able to list, view and comment on all assets owned by that team.
- Team Contributor: The member will be able to create new assets and edit, share all assets owned by that team.
- Team Admin: Same as Team Contributor + the member will be able to manage the team (add/remove members, edit metadata, etc).
If team members are not assigned any of those roles, they will be team members but won't be able to view or interact with any of the team's assets.
Team membership and team roles cascade down the team hierarchy.
In my example above, if a user is a Team Contributor in the team Engineering, this user would also be a Team Contributor in all the child teams (Development, DevOps, QA, etc)
Team membership can be explicit when a user is directly added to a team but it can also be implicit when inherited.
For example if a user is added explicitly as Team Contributor in team Development, then this user would also be an implicit member of the parent teams (Engineering).
Implicit members are, by default, not assigned any particular role in that team.
Make sure to add all platform users to their respective team and assign them the correct role so they can interact with the team's assets.
Global team permissions & Base user role
The Global Team is unique in the team structure, not only does it automatically contain all the members of the platform (no need to add them),
it is also where general roles and permissions are defined. As discussed above, team level roles define how users can interact with Experiments, Features, Templates, Goals & Metrics owned by that team,
everything else (who can create new Applications, who can manage Segments and API Keys) are platform level settings and are managed at the Global Team level.
For backward compatibility, it is still possible to assign permissions to Experiments, Features, Templates, Goals & Metrics at the Global Team level but it is not recommended as it would interfere and overwrite anything specified at the team level.
For example currently users with the built-in User role can view and list ANY experiment or metric irrespective of the role members have in their team.
For the new team level model to work correctly, you should refrain from granting any permissions on Experiments, Features, Templates, Goals & Metrics in a global team role.
To facilitate the transition to the new ownership model, we created a new (immutable) Base User role which contains all the basic permissions any user of the platform needs.
This role does not grant the user any permission to view or edit Experiments, Features, Templates, Goals & Metrics.
In time this role should replace the current User role assigned by default to all new users of the platform.
Review your current roles & permissions to align with the new model (Ideally no global roles, besides the fulladmin role, should grant permissions to Experiments, Features, Templates, Goals & Metrics) and start migrating your user from the User role to the new Base User.
If you need help automating this step please let us know. Once the migration is done, you can let us know so we can remove it and make Base User the new default role for all new users.
Sharing assets
All the features described above enable users to collaborate within their team but it does not allow them to share assets with other teams or individuals. For example a team owning a metric wants to make this metric available to all teams in Engineering or a team working on an experiment wants to allow specific users from other teams to collaborate on that experiment without making them owners.
To address this we introduced Asset level permissions (for Experiments, Features, Templates, Goals & Metrics) which is the ability to share an asset with other teams or individuals.
For now there are 2 types of possible permissions associated with sharing of assets.
- Can View: Grants the ability to search for, to view, comment on and to use this specific asset. A good use case for this is if you want to make your metric or a template available to another team or if you want other people to be able to view your experiment on the search page without being able to edit it.
- Can Edit: Grants the ability to edit and collaborate on this specific asset. A typical use case here is to invite other individuals to collaborate on an experiment or a feature.
Note: If Can View or Can Edit is granted to a team, then all members of that team will be able to view/edit that asset irrespective of their role in that team.
Following the least privilege principle, and unless there is a good reason, it is usually good practice to grant Can Edit only to relevant individuals.
Go over your list of Experiments, Features, Templates, Goals & Metrics that you own (or that your team owns) and make sure to share it with the relevant individual(s) or team(s). For example if you want a metric or a goal to be available for everybody to use, then share it with the Global Team with Can View permission. It is possible that you want all your existing metrics, goals and possibly all your experiments, features and templates to be discoverable and usable by anyone on the platform. If this is the case, just let us know and we will run a script to automatically grant Can View to all your existing assets saving you loads of manual work.