Team Examples

The situation: Acme Retail has one production warehouse. Data engineers run profiles and scans and maintain the checks. Business analysts review checks and anomalies and need to see source records to investigate them, but must not change anything. Everyone else in the company should not see the warehouse at all.

Team configuration

API payload for the analysts' team:

{
  "name": "Business Analytics",
  "description": "Analysts who review checks and anomalies on the retail warehouse",
  "permission": "Viewer",
  "user_ids": [12, 15, 18, 21],
  "datastore_ids": [10]
}

What each person can do

Result: Each department has exactly the level its work needs, and the warehouse is invisible to people outside those two teams.

The situation: Acme Retail is about to connect its identity provider, so dozens of accounts will be created on first sign-in. Security wants new accounts to see no data until an Admin, or group sync, places them on a team.

Team configuration

Open the Public team with Edit a Team and clear both datastore fields. Its permission level then makes no difference, because there is nothing for it to apply to. The Public team's Name and users cannot be changed, and it cannot be deleted.

API payload (the Public team always has ID -1; only its permission and datastores are accepted):

{
  "name": "Public",
  "permission": "Reporter",
  "datastore_ids": []
}

Result: A person who signs in for the first time can open the platform and sees no datastores. Access begins when an Admin adds them to a team, or when group sync does it at their next sign-in.

The situation: Acme Retail's directory has a security group called ACME-DQ-PROD-ANALYSTS-RW. Membership of that group is what should decide who can author checks on the production warehouse, and nobody at Acme wants to read that string inside Qualytics.

Team configuration

API payload

{
  "name": "ACME-DQ-PROD-ANALYSTS-RW",
  "display_name": "Production Analysts",
  "description": "Filled by the ACME-DQ-PROD-ANALYSTS-RW directory group",
  "permission": "Author",
  "datastore_ids": [10]
}

Result: With Sync groups to Teams turned on for the sign-in provider, every person who carries that group is added to the team at their next sign-in, because the match uses the Name. Everywhere the team appears, people see Production Analysts; hovering over it in the Teams list shows the Name underneath. Removing someone from the directory group does not remove them from the team, so plan the reconciliation routine described in Just-in-Time Provisioning and Group Sync.

The situation: Acme Retail's finance team has two junior analysts who know the data well and should propose checks, and a data steward who decides which checks go live. Proposals must never run against the ledger until the steward approves them.

Team configuration

API payload for the contributors:

{
  "name": "Finance Contributors",
  "description": "Proposes checks on the finance ledger as drafts",
  "permission": "Drafter",
  "user_ids": [31, 32],
  "datastore_ids": [22]
}

What each person can do

Result: The review step lives in the permission model itself. Nothing a Drafter creates affects the ledger until an Author activates it. See Drafter and Author.

The situation: Acme Retail's head of finance sits on the stakeholders team that reads the ledger. The head also leads the data quality effort on it and needs to author checks. Adding them to a second team should raise their access, and adding them to the read-only team should never lower it.

Team configuration

Result: The head of finance gets Author on Finance Ledger, because the highest permission among a person's teams applies to each datastore. The other stakeholders stay at Viewer. Adding someone to a lower team never reduces what a higher team already grants, so teams can overlap freely.

The situation: Acme Retail's orchestration tool must trigger scans on the orders lakehouse after each nightly load, and the security team wants that automation to reach nothing else.

Team configuration

API payload

{
  "name": "Pipeline Automation",
  "description": "Service account that triggers scans on the orders lakehouse",
  "permission": "Editor",
  "user_ids": [204],
  "datastore_ids": [35]
}

Result: The Service User can trigger operations and manage checks on Orders Lakehouse and reaches no other datastore, apart from whatever the Public team grants. Give it the Member role and keep it off every other team. If a second pipeline needs a different datastore, create a second team rather than widening this one. See Team Membership on the Service Users page.

The situation: Acme Retail's compliance officers must see data quality results across every datastore for their audits, but they should never open source records or touch a check.

Team configuration

API payload

{
  "name": "Compliance",
  "description": "Read-only reporting access across all datastores for audits",
  "permission": "Reporter",
  "user_ids": [41, 42],
  "datastore_ids": [10, 22, 35, 48]
}

Result: The officers can open every datastore's reports, scores, checks, and anomaly lists, but source records stay hidden from them, which is the difference between Reporter and Viewer. When a new datastore is created, add it to the Compliance team so the audit view stays complete. See Reporter.

The situation: Acme Retail hires a consultancy for a three-month migration of the marketing warehouse. The consultants need full control of that one datastore and must lose it the day the engagement ends.

Team configuration

API payload

{
  "name": "Marketing Migration (Q4)",
  "description": "Consultancy engagement, ends 31 December",
  "permission": "Editor",
  "user_ids": [301, 302, 303],
  "datastore_ids": [48, 20]
}

Result: During the engagement the consultants work on the marketing warehouse like any engineer. When it ends, an Admin deletes the team: every consultant loses the access granted through it at once, while their accounts and any other memberships are untouched. Because Marketing Warehouse also belongs to Data Engineering, the deletion is not blocked; a datastore that belonged only to this team would have to be assigned elsewhere first. Deactivate the consultants' accounts as well if they should not sign in again.