How Teams Work
This page explains how teams work in Qualytics: what a team is, how access is granted, how a team's Name and Display Name differ, what the Teams list shows, and how teams relate to user roles.
What Teams Are
Teams group users together and define which datastores they can access and at what permission level. Each team carries one team permission (Editor, Author, Drafter, Viewer, or Reporter) that applies to every datastore assigned to it.
- Datastore-level access: Team permissions control which datastores and data assets (tables, fields, checks, anomalies) a user can interact with.
- Permission inheritance: All members of a team inherit the team's permission level for its assigned datastores.
- Multiple teams: Users can belong to multiple teams, each granting access to different datastores.
- Public team: Every user is automatically part of the Public team, which provides access to every datastore assigned to it.
- Admin override: Administrators are not subject to team permissions and can access all data assets.
Note
Permissions are assigned to Teams rather than directly to users. Users inherit the permissions of the teams to which they are assigned.
How Team Access Works
When a team is created, it is assigned a permission level and one or more datastores. All members of the team inherit that permission level for all datastores assigned to the team.
- An Admin creates a team and assigns a permission level (e.g., Editor)
- The Admin assigns datastores to the team
- The Admin adds users to the team
- All team members can now access those datastores at the assigned permission level
Note
If a user belongs to multiple teams with different permission levels for the same datastore, the highest permission level applies.
Permission Levels
There are five permission levels, organized from most to least privileged:
| Level | Permission | Purpose | Typical User |
|---|---|---|---|
| 5 | Editor | Full datastore management | Data Engineers, Platform Operators |
| 4 | Author | Quality check lifecycle management | Data Quality Analysts, Data Stewards |
| 3 | Drafter | Check creation (draft only) | Junior Analysts, Contributors |
| 2 | Viewer | Read access with source records | Business Analysts, Stakeholders |
| 1 | Reporter | Report and dashboard access | Executives, Compliance Officers |
Info
For the full permission matrix and detailed capability tables, see the Team Permissions page.
Teams vs User Roles
Teams and user roles serve different purposes:
| Aspect | User Roles | Team Permissions |
|---|---|---|
| Scope | Platform-level (global) | Datastore-level (scoped) |
| Controls | What features and actions a user can perform | Which datastores and data a user can access |
| Assigned to | Individual users | Groups of users |
| Examples | Admin can manage users; Member can generate tokens | Editor can run operations on assigned datastores |
Info
For details on user roles (Admin, Manager, Member), see the Personal Accounts documentation. For who can create and manage teams, see Team Management Permissions.
Name and Display Name
Each team carries two labels that serve different purposes.
| Field | Purpose | Rules |
|---|---|---|
| Name | The team's identifier. It is what group sync compares directory group names against, what the Delete Team dialog shows, and what Copy Name copies from a team's row. | Required and unique across the platform. |
| Display Name | A friendlier label shown in place of the Name in the Teams list, in the team pickers of the Edit User and datastore forms, and on the team badges of a datastore. | Optional. It does not have to be unique, and nothing matches on it. Clear it and the team shows its Name again. |
Use a Display Name when the Name has to match an identity-provider group whose name is unreadable, such as WF-DQ-PROD-ANALYSTS-RW. Keep that string as the Name so the match keeps working, and set the Display Name to something people recognize, such as Production Analysts. Because group sync matches on the Name only, renaming a team to make it friendlier silently breaks the match; change the Display Name instead. The Teams list shows the underlying Name in a tooltip on hover, so an Admin reconciling teams against the directory can always read it.
Searching and sorting
The Teams list is searched and sorted by the label on screen, so a team with a Display Name sorts by that label and is found by it. Searching also matches the underlying Name, so a team can still be found by its group name.
Where the Name still shows
The Teams column of the Users list labels each team badge with its Name, not its Display Name.
The Teams List
The Teams list on the Access page (Settings > Access > Teams ) shows one row per team. Users with the Manager or Admin role can open it; only the Admin role can add, edit, or delete teams from it. The columns run from left to right:
| Column | What it shows |
|---|---|
| Name | The team's label next to the team icon: the Display Name when one is set, otherwise the Name. Hover over the label for a tooltip with the team's Description and, when a Display Name is set, the underlying Name as well. |
| Users | The members as a row of avatars. When more members exist than fit, the extra ones collapse into a count badge. Hover over an avatar for the user's name, and click it to open that user. Teams with no members show --. |
| Source Datastores | The source datastores the team can access, as badges. Hover over a badge for the datastore name, and click it to open the datastore. |
| Enrichment Destinations | The enrichment datastores the team can access, in the same form. |
| Permission | The team permission its members receive on those datastores: Editor, Author, Drafter, Viewer, or Reporter. |
| Created | When the team was created, as relative time. Hover over it for the exact date and time in your local timezone. All timestamps are stored in UTC and converted by your browser. |
At the right end of each row, the vertical ellipsis opens the Edit and Delete actions for Admins. Right-clicking anywhere on a row opens a context menu with Copy Name, which copies the team's Name rather than its Display Name, the value you need when reconciling teams against identity-provider groups.
The controls above the list are covered in Sort Teams.
The Public Team
Every user is automatically a member of the Public team. The Public team:
- Cannot be deleted or renamed, and cannot be given a Display Name
- Cannot have its members modified (all users are always included)
- Provides access to all datastores assigned to it
- Has a team permission that Admins can change, like any other team
Tip
If users should have no default access, keep the Public team with no datastores assigned. Only assign datastores to specific teams where access is needed.
Lowering the Public team's permission affects who can create datastores
Creating a datastore requires the Manager role plus the Editor team permission on one of the new datastore's teams. Because every user is in the Public team, it is often the only team a Manager belongs to. If an Admin sets the Public team's permission below Editor, a Manager in that position can no longer create datastores until they are added to a team with Editor. The Add Datastore form tells them so directly.
Team Membership for Service Users
Service Users can also be assigned to teams to scope their API access to specific datastores. This is the recommended way to control what automated integrations can access.
Info
For more details on how team membership works with Service Users, see Team Membership on the Service Users page.
See Also
-
Examples
Team setups for common goals: least privilege by department, a locked-down Public team, a team filled by an identity-provider group, and more.
-
Best Practices
Team organization, permission assignment, Public team usage, and regular audits.
-
Permissions
User roles required to view, create, edit, and delete teams.