How Service Users Work

This page explains how Service Users work in Qualytics — from creation and authentication to lifecycle management and when to use them.

When to Use Service Users

Service Users are intended for secure, automated, and shared access to Qualytics. They provide consistent authentication for system-level workflows, ensuring stability and centralized management without dependency on individual user credentials.

Use Service Users For

• Data Pipeline Automation: Use Service Users to integrate Qualytics operations within your automated data workflows, such as Airflow, dbt, Azure Data Factory, or other ETL pipelines.

• Qualytics API Access: For programmatic interactions with Qualytics, such as managing resources or retrieving data through API calls, Service Users offer reliable, long-term access. See the Service Token API for endpoint details.

• Qualytics CLI Operations: Automate data quality workflows and recurring tasks using the Qualytics CLI without relying on personal user tokens.

• Data Catalog Integrations: Enable metadata synchronization and data lineage tracking with catalog platforms like Alation, Atlan, or other similar tools.

• Shared Automation: Use Service Users for any automation or integration shared across multiple team members or systems to maintain consistency, security, and proper audit control.

Avoid Using Personal Access Tokens (PATs) For

Personal Access Tokens (PATs) are meant for individual, short-term, or development use only. Avoid using them in the following scenarios:

• Shared Data Pipelines: Tokens should not be shared among users due to security risks.

• Production Integrations: Tokens may become invalid if the associated user is deactivated or their role changes.

• Team-wide API or CLI Automations: Difficult to manage and audit across multiple users.

• Long-running Integrations: PATs are tied to individual user lifecycles and are not suitable for continuous system-level access.

Team Membership

A Service User reaches only the datastores its teams cover, exactly like a person. Team membership is therefore the way to scope what an automation can touch.

• Public team: Every Service User is automatically a member of the Public team and receives whatever that team grants.
• Additional teams: Assign the Service User to one or more teams, on creation or later with Edit a Service User, and it gains those teams' datastores at those teams' permission levels.
• Access control: The Service User's user role (Member, Manager, or Admin) sets what it can do on the platform; its teams set which datastores it can do it on. An Admin Service User bypasses team scoping and reaches every datastore, so keep automation at Member or Manager unless it genuinely administers the platform.

Example 1: A data catalog integration that reads several domains. The Service User needs to read metadata across three teams' datastores and manage nothing.

{
  "name": "Alation Data Catalog Sync",
  "role": "Member",
  "teams": ["Data Engineering", "Analytics", "Finance Data"]
}

It reaches the Public team's datastores plus those of the three named teams, at each team's permission level.

Example 2: A pipeline that runs scans on one team's datastores. The Service User triggers operations after each load and must reach nothing else.

{
  "name": "Pipeline Automation",
  "role": "Member",
  "teams": ["Data Engineering"]
}

Because Data Engineering carries the Editor team permission, this Service User can trigger profiling and scanning operations and manage checks on that team's datastores, and on no others apart from the Public team's.

Quick Reference