Organizations

Organizations are the multi-tenant boundary in DAAM. All resources — databases, agents, policies, groups — are isolated per organization. Users can belong to multiple organizations with different roles in each. Organization slugs are auto-generated by the server to prevent squatting.

Overview

Each tenant in DAAM is an organization (org). Organizations provide hard isolation boundaries:

• Databases and agents belong to exactly one org.
• Policies and table grants are scoped through the database they belong to.
• Groups belong to one org and can only reference members within that org.
• Identity providers (OIDC, SAML, SCIM) are configured per org.
• Users are global but join orgs via memberships. A user can be an admin in one org and a member in another.

All requests are implicitly scoped to the current organization. Resources are invisible across tenant boundaries.

Creating an Organization

Organizations are created in two ways: during initial signup or from the org switcher.

During Signup

1. Visit the landing page and click Get Started.
2. Enter your email, password, and organization name.
3. On submit, DAAM creates your user account, a new organization (with an auto-generated slug), and an org membership with the admin role.
4. You are redirected to the org dashboard.

From the Org Switcher

1. While logged into an existing org, click the org switcher in the sidebar.
2. Click Create new organization.
3. Enter an organization name. The slug is auto-generated.
4. You are added as admin and re-authenticated into the new org.

Roles

Each org membership has one of two roles:

A user's role is per-org. The same person can be an admin in one org and a member in another. Admins can promote members to admin or demote admins to member from the Members page in the console.

Last Admin Protection

An organization must always have at least one admin. The sole admin cannot leave the organization, demote themselves to member, or be removed. To transfer ownership, promote another member to admin first.

Inviting Members

Users join organizations by accepting invites. There are two types of invites.

Email-Specific Invites

1. In the console, navigate to Members and click Invite user.
2. Enter the email address of the person to invite.
3. Select a role (admin or member).
4. Set an expiry (default: 7 days).
5. Click Send. An email with an invite link is sent to that address.

Only the invited email can accept the invite. If the recipient does not have a DAAM account, they can sign up and accept the invite in a single step — no throwaway org required.

Open Invite Links

1. In the console, navigate to Members and click Create invite link.
2. Select a role (admin or member).
3. Optionally set an expiry and a maximum number of uses.
4. Click Create. A shareable link is displayed for copying.

Anyone with the link can join the organization, subject to the configured limits. You can optionally restrict open invites to specific email domains using the domain allowlist.

Invite Settings

Expired invites and fully-used invites return an error when someone attempts to accept them.

Acceptance Flow

When a user clicks an invite link:

• If already logged in, they see a confirmation prompt and click Join to accept.
• If not logged in, they see a login or signup form. After authenticating, the invite is accepted automatically.
• For email-specific invites, the authenticated user's email must match the invite's target email.

On acceptance, the user is added to the org with the invite's role and re-authenticated into the new org.

Groups

Groups let you manage policy assignments at scale. Instead of assigning individual users to policies, assign a group — all group members automatically receive the policy's grants and masking rules.

Creating Groups

In the console, navigate to Groups and click Create Group. Enter a group name (unique within the org) and save. Then add members by searching for users by email.

Nested Groups

Groups can contain other groups as members. When a parent group is assigned to a policy, all members of all child groups (recursively) receive the policy's grants. This lets you model team hierarchies — for example, an "Engineering" parent group containing "Backend" and "Frontend" child groups.

Policy Assignment via Groups

When you assign a group to a policy, the effective policy for every group member is recomputed and pushed to agents immediately. When someone joins or leaves the group, their database access updates automatically — no manual policy reassignment needed.

Seat Tracking

DAAM uses a per-seat billing model. A seat is activated when an org member first connects to a database via the CLI. Provisioning users (via invites, SCIM, or OIDC JIT) does not consume seats — only developers who actively connect count as billable seats.

What Consumes a Seat

Seat Limits

The free tier provides 3 seats per organization. When a member without an activated seat connects via CLI, DAAM atomically checks capacity and activates the seat. If no seats are available, the connection is rejected with a 403 error indicating the seat limit has been reached.

Seats are sticky — once activated, a seat remains consumed until an admin explicitly deactivates it or the member is removed from the org.

Managing Seats

• Deactivate — An admin can deactivate a member's seat from the Members page, freeing it for another user. If the deactivated user reconnects, they re-consume a seat (subject to availability).
• Remove member — Removing a member from the org implicitly frees their seat.
• Reduce limit — If the seat limit is reduced below the current count of activated seats, existing seats remain active but new activations are blocked until the count drops.

Managing Your Organization

Organization settings are accessible from Settings in the console sidebar. Admins can view and update:

• Organization name — The display name shown in the console and org switcher.
• Slug — Read-only. The auto-generated URL identifier for your org.
• SSO settings — Configure identity providers, enable Force SSO, and set a default provider.
• Notification channels — Configure webhook endpoints for event notifications.

Force SSO

When Force SSO is enabled, local password authentication is disabled for all org members. The login page hides the password form and shows only SSO options. At least one identity provider must be configured before Force SSO can be enabled.

Deleting an Organization

Admins can delete an organization from the Settings page. Deletion is a soft delete:

• The org status is set to "deleted" and a timestamp is recorded.
• All active sessions and tokens are invalidated.
• Agents lose their connection to the control plane and cannot reconnect.
• Console and CLI login are blocked for this org.
• The org slug remains reserved (cannot be claimed by a new org).

Restoring a Deleted Organization

Deletion is reversible. A former admin can restore the organization from the restore page. On success, the org returns to active status and agents can reconnect.

Member Removal and Active Connections

When an admin removes a member from the organization, or when a user leaves voluntarily:

1. The org membership is deleted, implicitly freeing their seat.
2. The control plane recomputes the user's effective policy on every database where they had access.
3. Since the user no longer has any policy assignments, agents receive a policy removal.
4. Agents terminate any active database connections for that user.

This ensures that removed users immediately lose database access, even if they have open connections at the time of removal.