Skip to main content

Access Management Model

Overview​

Definity is designed as an internal organizational tool — the philosophy is that full observability across all data pipelines should be available to all members of the data team. Access management therefore prioritizes broad visibility by default, with controlled editability governed by ownership.

Roles​

There are two role types within a Definity tenant:

Admin​

  • Can invite, remove, and manage users within the tenant
  • Can reset passwords and manage user accounts
  • Has Edit access to all pipelines by default (no ownership step required)
  • Responsible for tenant administration during onboarding and ongoing operations

Standard User​

  • Can access the platform and view all pipeline observability data
  • Has View access to all pipelines by default
  • Can acquire Edit access to specific pipelines via the ownership model (see below)

definity does not support adding other role types​

Pipeline Access Levels​

All pipelines within a tenant have two access levels:

View (Default for all users)​

Every authenticated user in the tenant has full View access to every pipeline. This includes:

  • Pipeline observability and health metrics
  • Lineage graphs
  • Data quality insights and test results
  • Incident history and alerts
  • Performance analysis and recommendations

Design intent: Observability is most powerful when the entire data organization can see the full picture. Restricting pipeline visibility by team or role would undermine root cause analysis and cross-team awareness.

Edit (Ownership-gated)​

Edit access allows a user to:

  • Tune and configure data quality tests
  • Set and modify alerts
  • Apply auto-tuning and remediation actions (roadmap)

Edit access is granted through the Pipeline Ownership Model (see below).

Pipeline Ownership Model​

Definity uses a pipeline ownership model to govern Edit access. The core principles are:

  1. Any user can request ownership of any pipeline. Since Definity is an internal organizational tool, the assumption is that all users are trusted members of the data team. There is no approval gate by default — ownership is self-service.

  2. Becoming an owner grants Edit access to that pipeline. A user may own multiple pipelines.

  3. Admins have Edit access to all pipelines by default, without needing to claim ownership.

  4. Ownership is visible within the platform, so it is clear who is responsible for each pipeline's configuration and alert settings.

Summary Table​

CapabilityStandard User (no ownership)Standard User (owner)Admin
View all pipeline metrics & lineage✅✅✅
View all insights and incidents✅✅✅
Tune tests and configure alerts❌✅ (owned pipelines)✅ (all pipelines)
Apply auto-tuning (roadmap)❌✅ (owned pipelines)✅ (all pipelines)
Invite / remove users❌❌✅
Manage user accounts❌❌✅
Claim ownership of any pipeline✅✅✅ (already has Edit)

For customers onboarding to Definity (e.g., during POC)​

  1. Designate at least one Admin — this should be a data platform lead or team manager responsible for user provisioning. Limit the number of Admins to those with a genuine administrative need.

  2. Enable SSO from day one — configure your Identity Provider (e.g., Okta) as the authentication source before inviting users. This ensures that leavers automatically lose access when their IdP account is deprovisioned, with no manual cleanup required in Definity.

  3. Treat tenant access as privileged during POC — since the current model grants all users full View access to all pipelines, only invite team members who have a legitimate need to observe the pipelines in scope for the POC. Do not broadly provision the full organization during evaluation.

  4. Use environments to scope the POC — create a dedicated environment within the tenant for POC pipelines, separate from any future production rollout. This limits the blast radius of any misconfiguration during evaluation.

  5. Communicate the ownership model to the team — make sure all users understand that claiming pipeline ownership is intentional and grants Edit rights. Teams should establish informal norms about who owns which pipelines to avoid conflicting configurations.

  6. Rotate API tokens regularly — any non-human systems or automated integrations connecting via the Definity API should use tokens with documented owners. Establish a rotation cadence (recommended: 90 days or less) and store tokens in a secrets manager, never in source code.

Access Revocation​

  • User offboarding: Admins can remove users directly from the tenant UI. If SSO is enabled, deprovisioning the user in the IdP immediately blocks access regardless of their Definity account state.
  • API token revocation: Tokens can be revoked in the platform UI immediately. Revocation takes effect on the next request.
  • Full tenant offboarding: Initiated via a formal request to Definity. Definity will coordinate secure data export and deletion confirmation on a documented SLA.

For questions about access management, contact: [email protected]

Last updated on