Integrations and Admin

Integrations and admin settings connect ClariLayer's context layer to the systems an organization already uses, while keeping ownership, access, billing, security, and approval controls visible to the right operators.

This page is a public overview of those product areas and current integration boundaries. It is not a connector setup runbook or a private operations guide.

Projects and warehouses

Projects are the packaging boundary for metric work. They group metric definitions, release targets, warehouse context, and downstream handoff assumptions so a team can reason about one governed area at a time. Cross-project dependencies should be explicit because a release bundle needs to preserve which metric version, environment, dependency snapshot, and validation evidence were reviewed together.

Warehouse connections provide the technical context behind validation and deployment. The shared product path covers catalog browse, validation probes, direct deployment, and rollback across Databricks, Snowflake, and BigQuery.

One boundary matters for monitoring: live Observe and query-history ingest are Databricks-only today. A Snowflake or BigQuery metric can still be authored, validated, released, deployed where eligible, rolled back where eligible, and served through the API, but it does not yet carry query-history-driven Observe evidence.

Settings areas

Settings are role-gated admin surfaces for operating the organization. The public model is:

• Team access manages members, invites, and organization roles.
• Billing shows the organization's commercial state and recovery path.
• Security covers identity configuration such as SAML, OIDC pilot configuration, and SCIM directory controls.
• Integrations manages warehouse-adjacent and release-adjacent connector state, including GitHub, Jira, and approval webhooks.
• Audit gives admins a review surface for organization-management activity.
• Approval Workflows lets authorized reviewers and admins inspect or manage governance rules.

Admins and owners can manage the broader Settings areas. Approvers have intentionally limited visibility: they can see the Approval Workflows area needed for governance review without receiving broad access to billing, security, team administration, connector secrets, or unrelated organization controls.

Supported integration categories

ClariLayer supports several integration categories at different depths:

Category	Public boundary
Warehouses	Databricks, Snowflake, and BigQuery share the live catalog, validation, deployment, and rollback product path; Databricks remains the deepest live path because Observe query-history ingest is Databricks-only.
dbt	Local dbt YAML export is live. Server-owned repository sync is not part of the current public product path, even though generator and writer libraries exist.
Identity	SAML 2.0 through the underlying SSO provider, native OIDC routes and admin configuration for pilot use, and SCIM v2 Users plus Groups for one directory per organization.
GitHub and Jira	Organization-scoped token connectors are the live release-readiness path for source-control and ticket handoff. OAuth, App installation, and workspace-discovery signals can exist as supporting state but are not the release-readiness boundary.
Notifications	In-app notification surfaces support product workflow awareness.
Approval email queue	Approval email delivery is durable and worker-backed. It is a queue-backed approval notification path, not a generic email operations dashboard.
Approval webhooks	Approval-centric webhook subscriptions support durable delivery, replay, admin inspection, and shipped metric lifecycle events.

These categories are intentionally specific. ClariLayer is not claiming to replace a warehouse, semantic layer, identity provider, ticketing system, or notification platform. It connects to those systems so governed metric context can move through the lifecycle with the right evidence attached.

In short, the public categories are warehouses, dbt YAML export, identity with SAML, OIDC, and SCIM, GitHub and Jira release handoff, notifications, the approval email queue, approval webhooks, and billing-aware enterprise controls.

Identity and access

Human access starts with organization membership and role checks. Admin and owner roles operate team, billing, security, integrations, audit, and organization administration surfaces. Editors can participate in metric work where allowed by the workflow. Approvers can review governance work through the approval surface without broad administrative reach.

Machine access is separate. API keys are organization-scoped bearer credentials for the public v1 read API. Service accounts are organization-admin-managed machine principals for deployment automation surfaces. Service accounts do not replace API keys for metric list, detail, or contract reads. Use API v1 Authentication when planning an external reader, AI agent, or BI integration that needs governed metric context.

SCIM supports user and group directory objects for one directory per organization. Group objects exist, but group-to-role expansion is not part of the current public boundary. That means a directory can synchronize identity shape without promising that every external group assignment automatically maps to ClariLayer roles.

Billing and enterprise controls

Billing is an admin control surface, not a public pricing calculator embedded inside docs. The organization plan and billing status shape workspace eligibility, recovery flows, quota posture, and enterprise controls. Reads, billing recovery, and security cleanup should remain available when an account needs recovery, while value-expanding writes can be blocked according to billing and pause state.

Enterprise controls focus on operational safety: role-gated administration, organization-scoped connectors, encrypted secret storage, audit history, approval workflow visibility, release-bundle immutability, and fail-closed handoff behavior. The important public promise is not that every connector can do everything. The promise is that the release and admin paths make trust boundaries explicit.

Release and notification boundaries

The live GitHub and Jira release handoff uses the saved organization-scoped token connector configured in Settings. GitHub OAuth, GitHub App installation tracking, Jira OAuth, and Jira workspace discovery are supporting foundations, not substitutes for the saved connector target that determines release readiness.

This boundary keeps release behavior auditable. If the source-control or ticketing handoff cannot complete authoritatively, the release path should fail closed rather than creating a partial governance story.

Approval notifications follow the same posture. In-app notifications, durable approval email delivery, and approval webhooks help the right people and systems react to governance work. Webhook subscriptions and delivery inspection are admin-owned because outbound integration targets, signing secrets, replay actions, and failure history belong to organization operations.

How this fits the product journey

Integrations and admin controls sit around the core metric lifecycle:

1. Projects and warehouse connections give Metric Studio and validation the context they need.
2. Team access and identity decide who can author, review, approve, and administer.
3. Billing and enterprise controls shape workspace eligibility and operational recovery.
4. Approval workflows decide which metrics can become trusted released context.
5. GitHub, Jira, dbt export, notifications, approval email delivery, and approval webhooks carry governed context into downstream workflows.
6. The public v1 API gives external readers and AI agents the approved context after the lifecycle has done its work.

For the lifecycle mechanics, read Governance and Release. For warehouse validation depth, read Warehouse Validation. For external read access, start with API v1 Authentication.