# Managing organizations
> Learn how to manage your organization with MotherDuck
An organization is a top-level entity in MotherDuck that lets you perform administrative functions, such as managing users, setting up billing, configuring sharing, and monitoring security. A MotherDuck user can only belong to a single organization at a time. Multi-organization membership support is planned for a future release.

Organizations are helpful for:

- Grouping users together for tracking usage and billing.
- Sharing data with other users of the same organization.

:::note
MotherDuck is available on six AWS regions:
- **US East (N. Virginia):** `us-east-1`, supporting DuckDB versions between 1.4.0 and 1.5.4.
- **US West (Oregon):** `us-west-2`, supporting DuckDB versions between 1.4.1 and 1.5.4.
- **Europe (Frankfurt):** `eu-central-1`, supporting DuckDB versions between 1.4.1 and 1.5.4.
- **Europe (Dublin):** `eu-west-1`, supporting DuckDB versions between 1.4.1 and 1.5.4.
- **Asia Pacific (Tokyo):** `ap-northeast-1`, supporting DuckDB versions between 1.4.1 and 1.5.4.
- **Asia Pacific (Sydney):** `ap-southeast-2`, supporting DuckDB versions between 1.4.1 and 1.5.4.

You can choose the region in which to create your organization. Organizations can only exist within a single cloud region. See [Cloud regions](/about-motherduck/cloud-regions/) for the full list and regional details.
:::

## Creating an organization

If you already have a MotherDuck account, an organization was already created for you by MotherDuck.

If you are a new MotherDuck user, during sign-up you will be prompted to create a new organization.

![create_org](./img/create_org.png)

:::note
If another coworker at your company already has an organization, you can create your own organization to get started with MotherDuck right away, and then ask them to invite you to their organization later (see ["Joining an existing organization"](#joining-an-existing-organization) below).
:::

## Inviting users to your organization

Viewing organization members and their roles requires permission to view members. Every preset role includes this permission by default. You can check whether teammates are in your organization by navigating to the MotherDuck UI → **Settings** → **Members**.

Inviting teammates requires permission to invite members. The Admin preset role includes this permission by default. The organization invite policy can also grant it to Builder and Explorer users. You can invite teammates without a MotherDuck account and existing MotherDuck users.

![members](./img/members.png)

Changing the organization invite policy requires permission to manage the invite policy, which the Admin preset role includes by default. When member invitations are disabled, only users whose roles include permission to invite members can invite new users. You can configure this setting from the organization **Settings** page.

![invite policy](../authenticating-and-connecting-to-motherduck/authenticating-to-motherduck/img/org-invite-policy.png)

:::tip
If your organization has [SSO enabled](/docs/key-tasks/authenticating-and-connecting-to-motherduck/authenticating-to-motherduck/sso-setup/) you can use
[Just-in-Time (JIT) provisioning](/docs/key-tasks/authenticating-and-connecting-to-motherduck/authenticating-to-motherduck/sso-setup/#just-in-time-jit-user-provisioning) enabled, users in your verified domains who authenticate through your identity provider can join the organization on first login without needing an invitation.
:::

## Joining an existing organization

If you'd like to join your teammates' existing MotherDuck organization, a member with permission to invite members must invite you. The Admin preset role includes this permission by default; the invite policy can also grant it to Builder and Explorer users. Once an invite is generated, you receive an email with a link to join the organization.

## Roles

Roles control what a member can do in the MotherDuck platform and which data they can read. MotherDuck provides three preset roles in a concentric hierarchy: **Admin**, **Builder**, and **Explorer**. The first user in an organization is an Admin, and members invited afterward default to Explorer. Creating custom roles requires permission to create custom roles. Assigning roles to members requires a separate permission to assign roles. The Admin preset role includes both permissions by default.

Organizations created before role-based access control keep their access: existing Admins remain Admin, and existing Members become Explorer.

:::note
Managing users and roles, changing plans, and updating billing information require the corresponding platform permissions. The Admin preset role includes these permissions by default.
:::

For the full role model, the capability breakdown, and setup steps, see [Roles and access control](/docs/concepts/roles-and-access-control/) and [Manage roles and access](/docs/key-tasks/managing-organizations/managing-roles/).

## Deprovisioning users

Deprovisioning a user requires permission to deprovision members. Reactivating a user requires a separate permission to reactivate members. The Admin preset role includes both permissions by default. If you need to revoke a user's access without deleting their data, deprovision them from the context menu in the [Members table](https://app.motherduck.com/settings/members). Deprovisioning is a reversible alternative to [removing](#removing-users) a user.

When you deprovision a user:

- They can no longer sign in to MotherDuck.
- Their personal access tokens and short-lived tokens are revoked.
- Their account, databases, and shares are retained.

To restore access later, choose **Reactivate** from the same context menu. The user can sign in again, but previously revoked tokens are not restored — they need to create new tokens.

Two actions are blocked:

- You can't deprovision yourself.
- You can't deprovision the last active user in the organization.

:::note
If your organization uses SCIM provisioning, user lifecycle is managed by your identity provider and the deprovision and reactivate actions are hidden from the Members table.
:::

## Removing users

Removing a member requires permission to remove members, which the Admin preset role includes by default. If a user leaves your team or no longer needs access, remove them from the organization to restrict data access or clean up resources that are no longer used. This is done from the context menu in the [Members table](https://app.motherduck.com/settings/members).

:::warning
Because a user can only belong to one organization, removing them from the organization permanently deletes the user and all of their data. This action cannot be undone. To revoke access reversibly instead, [deprovision](#deprovisioning-users) the user.
:::

## Limitations

- It is not possible to search for existing organizations to join. Please reach out to other MotherDuck users at your company or [contact us](../../troubleshooting/support.md) if you would like to find other existing users at your company.


---

## Docs feedback

MotherDuck accepts optional user-submitted feedback about this page at `GET https://motherduck.com/docs/api/feedback/agent`.
For agents and automated tools, feedback submission should be user-confirmed before sending.

URL-encode query parameter values and send a GET request:

```text
GET https://motherduck.com/docs/api/feedback/agent?page_path=%2Fkey-tasks%2Fmanaging-organizations%2F&page_title=Managing%20organizations&text=<url-encoded user feedback, max 2000 characters>
```

Optionally append `&source=<url-encoded interface identifier>` such as `claude.ai` or `chatgpt`.

`page_path` and `text` are required; `page_title` and `source` are optional. Responses: `200 {"feedback_id": "<uuid>"}`, `400` for malformed query parameters, and `429` when rate-limited.
