Groups, Teams & Roles¶
A user’s roles and permissions determine what they can or cannot do within Tree Schema. We try to keep things simple, intuitive, and easy to understand.
Groups¶
A user’s group determines their ability to:
Invite or remove other users
Create and manage admins
Create teams
Create Data Stores
Create & manage Jump Servers
Group |
Permissions |
Owner |
Everything as Admin, plus: Create or remove admins, see data in all Data Stores, and manage the account. The user that creates the account is automatically placed in this group. |
Admin |
Everything as User, plus: Can invite other users, remove users, create teams, create Data Stores, manage users within any team and assign elevated Data Store access to teams. |
User |
Can be invited to Tree Schema and invited to teams User’s have full access to view the entire Catalog, create keywords, manage tags, complete governance actions, view lineage, create & manage transformations, add comments, upload sample files, create & manage sample field values and more. |
Teams¶
Users are added to one or more teams and one or more teams can be given elevated access to each Data Stores. The elevated access cascades down through the Data Store and applies to all of the schemas and fields that exist within the Data Store.
There are three main differences in the privelages available to users who are in a team that has elevated access for a Data Store and those that do not have elevated access:
Whether or not the connection to the Data Store can be edited, this includes things such as the hostname, password, database name, whether a jump server is used to connect, etc. Everyone has the ability to edit basic information such as the name and points of contact.
The ability to populate Tree Schema directly from your Data Store. Tree Schema never accesses your Data Store without your explicit invocation and only the users in teams with elevated access will be able to create new schemas and update existing schemas by connecting directly to a Data Store.
Viewing sensitive information within Data Field examples and managing who has the ability to classify field as “viewable” to everyone else.
By default all field values are “viewable” by everyone, but users that are a part of one or more teams with elevated access can mark a field as “not viewable” by users without elevated access. This may be beneficial if some of your sample values are senstive and you do not want everyone in your orgnaizaiton to have access, such as the user’s email address.
The following table summarizes the differences:
User is in 1+ teams with elevated access? |
Permissions |
Yes |
Everything as the row below, plus: Users can edit Data Store connections (e.g. host, username, password, jump host) Users can view all sample values for all fields within a Data Store and they can mark sample values as viewable or not viewable for users who do not have elevated access. |
No |
Users can edit Data Store, Schema & Field information, including
Users can create, edit and remove both Tags & Attributes Users can view sample values for Data Fields if the sample value is marked as “viewable” |
Note
Users in the Admin or Owner group will automatically have elevated privelages to all Data Stores
Roles¶
A user has a role within each team; roles allow certain users the ability to manage access to the team.
Role |
Permissions |
Team Lead |
Everything as Team Member, plus: Can assign additional team leads, invite existing users to the team, and remove users from the team. Once a user has been assigned as a team lead only they can step down from the role or leave the team. However, Group Admins / Owners, may remove the team lead role from any user. The user that creates the team is automatically given this role. |
Team Member |
Receives elevated data access to all Data Stores (and their corresponding Data Schemas & Fields) that are assigned to the team. |
Note
One of the guiding principles we have here at Tree Schema is that all users should be able to see and read the metadata about all of the data that exists in the ecosystem around them. However, only the teams that have read access for a given Data Store will be able to see the underlying data.
Examples¶
Let’s consider an example scenario where there is 1 Data Store, 2 teams and 3 different users to see what the permissions will be:
Users
Users |
Group |
Asher |
Admin |
Emily |
User |
Dinah |
User |
Teams & User Assignment
Team |
Users |
default |
Asher, Emily, Dinah |
Data Engineers |
Emily |
Data Stores & Teams with Elevated Privelages
Data Store |
Elevated Team Access |
Marketing DB |
Data Engineers |
Privelages
Now that we have set up the example and we have 1 Admin (Asher) and 1 User who is in a team with elevated access to the Marketing DB, let’s look at the permissions for each user: