Organizations
Organizations are the top-level unit of access and billing in dbdeux. Every workspace, project, member, and AI budget belongs to an organization.
Organization Switcher
A global organization switcher sits in the left navigation panel. If you belong to multiple organizations, click the switcher to change your active context instantly without a full page reload. Each organization shows its display name and a distinct avatar.
The switcher includes a search field that filters the org list as you type, making it fast to find the right org even if you belong to many.
Organization Settings
Organization settings are divided into tabs. On a smaller screen, the tabs that do not fit collapse into a More menu, so every tab stays one click away:
Overview
General information about the organization: display name, creation date, and plan details.
Members
Manage who has access to the organization:
- Invite members by email, with the role they should have when they arrive
- Assign roles: Admin, Member, or Viewer
- Remove members who no longer need access
- View each member's last active date
Admins can manage settings, budgets, and members. Members can access projects and use platform features within the org's budget. Viewers can look but not change.
Inviting Someone Who Has Never Used dbdeux
Most invitations go to people who do not have an account yet. Type their email address on the Members tab and pick a role. They receive an email with a link to set their password, and the moment they first sign in the membership becomes active with exactly the role you chose. Until then nothing has been granted: a pending invitation is a promise, not access.
A few rules keep this safe without anyone having to think about them:
- You cannot grant more than you hold. Nobody can invite someone into a role above their own, and ownership itself is never handed out by invitation
- Only owners and admins invite from the Members tab
- Existing members are picked, not re-invited. If the address already belongs to a member, dbdeux tells you so rather than sending a duplicate invitation
- Invitations expire after a set number of days. An expired invitation stays visible so you can see who never followed through, and Resend issues a fresh link and a fresh expiry
- Revoke withdraws an invitation before it is accepted, and the record stays in the list marked as revoked, so the history of who was invited and by whom is never lost
- Delivery is confirmed, not assumed. If the email could not be sent, the invitation is still saved and clearly marked so you can resend it, rather than silently vanishing
- Every invitation, resend, revoke, and acceptance is written to the Audit Log
The Invitations card below the member list shows what is pending and expired, with a toggle to include accepted and revoked history.
Invitations also work from inside Atlas Catalog: when you assign an owner and the right person is not a member yet, type their email and they are invited and pencilled in as owner in one step.
Plan and Limits
The Plan & Limits tab shows exactly what your organization is entitled to, so nothing about your plan is a mystery until you hit a wall.
- Your plan is named at the top, with every limit that applies to it listed in one table
- Live usage is shown next to each counted limit, so you can see that you are using 4 of 10 projects at a glance. The number turns amber as you approach a limit and red once you reach it, giving you warning before anything blocks
- Features are listed as included or not included on your plan, so there is no guessing about what you have access to
- Clear messages when a limit applies: if an action would exceed a limit, dbdeux explains which limit was reached and what to do about it, instead of failing with a generic error
- Documentation history is one of the listed allowances: how many published catalog versions are kept per project and environment. Older versions beyond that are cleaned up automatically, and a version that a live share link is pinned to is always kept
- Run history is listed the same way: how many days of finished job runs stay in recent history before they move to the read-only archive. At least 90 days on every plan, longer on higher plans
- Routing rules counts the organization's notification routing rules against the plan, with the same amber and red warnings before the limit blocks
Every member can view the tab. Changing plans or raising a limit is handled by dbdeux, so reach out to us and we will take care of it.
AI Budget
Control how much your organization spends on AI features (Atlas chat, AI code review, test generation):
- Monthly limit: Set a spending cap per month. Usage is tracked in real time
- Usage breakdown: See spend by user and by feature
- Spending alerts: When the limit is reached, AI features pause until the next cycle or until an admin adjusts the limit
- Adjust anytime: Admins can increase or modify the budget at any point
- Export usage: Download a CSV of all AI usage for the current billing period
AI Providers
Decide which AI models power Atlas, AI documentation and test generation, and Slimmer CI review for the whole organization, and whose account pays for them:
- Four providers: Anthropic (Claude), OpenAI (GPT), Google Gemini, and Azure OpenAI (your own Azure resource and deployment)
- Managed or bring your own: let dbdeux supply the credential and bill usage against the organization's AI budget, or paste your organization's own key. A key you paste is stored once, never shown again, and can be replaced later without re-entering anything else
- Validate before you rely on it: each provider shows Validated, Validation failed, Key missing, or Disabled, so a broken key is found on this tab, not by a developer mid-task
- Default provider and model: pick which provider answers when a member has not chosen one, and the default model for it. An optional base address covers organizations that route AI traffic through their own gateway
- Personal keys as fallback: allow members to use their own keys when no organization provider can answer, or switch that off so everything goes through what you configured
- One switch for all AI features: turn AI off for every member of the organization at once and back on again. The tab always says plainly whether AI features are on and whether any provider can currently serve a request
Cost Insights
What your dbt work costs in the warehouse, attributed to the job, run, model, environment, and developer that caused it, with what failed runs cost and what state-aware runs saved. See Cost Insights for the full walkthrough and an animated tour.
Webhooks
Send signed run and notification events to your own systems, the ticketing tool, the data platform's event bus, a status board, whatever listens for HTTPS calls:
- Three steps to a webhook: the endpoint (https only), the events it should receive, and optional filters so it only fires for chosen jobs or environments. Organization-level events such as plan and budget alerts go to webhooks without filters
- Every event you can route is available: run started, completed, errored, and recovered, still failing, missed schedule, slow run, post-run action failed, source freshness failed, upstream source unavailable, maintenance mode started and ended, change request status, Snowflake password deadline, sign in to Snowflake again, plan limit near or reached, and AI budget warning or blocked. Each ticked event is one delivery
- Signed, and you hold the secret: a signing secret is generated for you (or you type your own) and shown exactly once, so your endpoint can verify each delivery really came from dbdeux. Rotate secret issues a new one and retires the old one immediately
- Test endpoint sends a sample delivery on demand, so you know the receiver answers before a real run depends on it
- Delivery history keeps every attempt with the payload dbdeux sent and the exact response your endpoint returned (or the fact that it did not answer within ten seconds). Redeliver sends the same event again once the endpoint is fixed
- Nothing fails silently: after ten consecutive failed deliveries the webhook pauses itself, the reason and time appear on its card, and re-enabling is one click from the menu once Test endpoint passes
- Pause without deleting: switch a webhook off and keep its configuration and history for later
Only organization owners and admins create or change webhooks; every member can see them. Creating, changing, rotating, pausing, and deleting are written to the Audit Log. Prefer a webhook that a specific alert rule fires? The Notifications hub offers a signed webhook as a rule destination too; this tab is for systems that want the raw run events, filtered by job or environment.
Notifications
The organization's alerting home, laid out as a short guided path:
- Connect Slack once, then pick channels from a list everywhere a channel is asked for
- Default Slack channel and email recipients for the whole organization. A scheduled job that leaves its own fields blank uses these, so a new job is never silently unmonitored, and setting either field on a job replaces the default for that job only
- Routing rules for job health (still failing, recovered, missed schedule, slow run), workspace and catalog events, and account and plan alerts, each delivered to any mix of Slack, Teams, PagerDuty, email, signed webhook, and the in-app bell, with cooldown and quiet hours
- Daily digest: one summary a day on top of immediate alerts
- Delivery history for the whole organization, newest first, with filters
- Notify me on Slack: personal Slack direct messages when your job fails, a request or question is addressed to you, or a model you own changes, visible only to you
See Notifications for the full walkthrough and an animated tour.
Service Accounts
Create machine identities and scoped API tokens so external systems can call dbdeux programmatically:
- Create service accounts for CI pipelines, orchestrators, or scripts
- Mint scoped tokens with per-token expiry, rate limits, and optional IP allowlists
- Rotate or revoke tokens at any time
See Service Accounts & API for the full workflow and API reference.
MCP Server
Connect AI assistants such as Claude and Cursor to your projects. The tab gives you the connection address, ready-made configuration to paste into each client, the full list of permissions you can grant, and the assistants you have already connected, each with a Revoke button.
See AI Assistants for the setup, what an assistant can do with each permission, and how to review connected assistants.
Settings
Three organization-wide defaults that used to need a request to support:
- Reuse parser state between deployment runs by default: let scheduled runs start from dbt's saved parse of the project instead of reading every file again, for a faster start on large projects. Any environment can still switch this on or off for itself from its Overview tab, so a default that suits most environments never traps the one that is different
- Who may move to dbt 2.0: either only organization owners and admins can switch an environment, or pin a scheduled job, to the dbt 2.0 engine, or any member who can edit the environment or job may. Members can keep using environments that are already on 2.0 either way
- Let AI assistants register themselves: allow an assistant to register with the organization's MCP server before a member signs in to authorize it, then let members approve those assistants and use them with their own permissions. When this is off, a member who is asked for access by such an assistant sees a message pointing here. Service account tokens from the MCP Server tab keep working in both modes
Every member can read the settings; owners and admins change them.
Access URLs
One card with every address a tool outside dbdeux might ask for, each with a Copy button and a plain-language explanation of what it is for and how it signs in:
| Address | What it is for |
|---|---|
| Public API | Automation with a service account token |
| API reference | Interactive documentation for every endpoint, with request and response examples |
| Semantic Layer query API | Governed metric queries from scripts and applications |
| Semantic Layer GraphQL | The same metrics for tools that speak GraphQL |
| MCP server (AI assistants) | The address to paste into Claude, Cursor, or any MCP client |
| Semantic Layer MCP (metrics only) | A narrower assistant connection limited to published metrics |
| BI tools: Arrow Flight SQL | Tableau, DBeaver, notebooks, and other SQL tools reading your published metrics as tables. See BI Tools Read Metrics as Tables |
Your organization ID is on the same card for the rare support request that needs it. Anything not switched on for your organization is listed as such rather than left out, so nobody hunts for an address that does not exist.
Clone Policies
Decide which warehouse connections developers may clone into their own managed dev databases, and for how long:
- Allowlist a connection, and optionally a single database on it, rather than opening cloning up everywhere. Without a policy, cloning is not possible at all
- Set a lifetime so every clone created under the policy expires and is cleaned up automatically instead of quietly accumulating cost
- Pause without deleting: deactivate a policy to stop new clones while keeping the configuration for later, or remove it entirely
- Visible to everyone: members who cannot change policies still see the list, so a developer always knows why a clone is or is not available to them
Warehouses that do not support cloning are shown in the picker with an explanation rather than silently omitted.
Migration
Bring an existing dbt Cloud setup into the organization. See Migrating from dbt Cloud for what is imported and how the reviewable, preview-first flow works.
Organization Isolation
All resources are scoped to the active organization:
- Projects: Each project belongs to a single org. Switching orgs shows only that org's projects
- Connections: Warehouse credentials are org-scoped, so different teams can use different warehouses without overlap
- Databases: The Database Explorer shows only connections belonging to the active org
- AI Budgets: Usage and spend limits are tracked independently per org
When you switch organizations, all resources (projects, connections, databases) reload automatically to reflect the new context.
Multi-Organization Support
Users who belong to multiple organizations can:
- Switch between orgs instantly via the nav switcher
- See which org is currently active at all times
- Have separate projects, connections, and budgets per org