> ## Documentation Index
> Fetch the complete documentation index at: https://docs.famulor.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Workspaces

> Switch workspaces, create additional ones, and manage each workspace's profile and team

A **workspace** keeps its assistants, calls, campaigns, knowledge, phone numbers, plan, credits, and billing separate. Signing up creates your first workspace automatically.

You can also join other workspaces and, when your plan allows it, create additional workspaces of your own.

## Switching workspaces

Select the workspace avatar at the top of the sidebar. The switcher lists every workspace you can access and your role in each one. Choosing a workspace reloads the dashboard with that workspace's data.

Your selection affects only your own session. Other members keep their current workspace.

## Creating another workspace

Open the workspace switcher and choose **New workspace**. The dialog shows whether your account can create another workspace and prompts you to choose a name.

The number of additional workspaces depends on your plan and the **Extra Workspaces** add-on — extra capacity bought per additional workspace from **Settings → Plan**, the same way the other capacity add-ons work. Joining someone else's workspace does not consume your creation allowance. Existing workspaces remain accessible if your allowance later changes; the limit applies when creating a new one.

Each new workspace starts separately, so review its plan and billing before adding production resources.

## Workspace profile

Open **Settings → Workspace** to view and edit the active workspace's identity and defaults: its logo, name, company website, timezone, date format, and the default language for members who haven't chosen one themselves. Owners and admins can change these fields; every other role sees the same fields read-only. The page also shows the workspace ID — read-only, and the value to quote in [support requests](/support) and API calls.

**AI inference region** controls where Famulor runs the AI processing behind this workspace — the language-model work in conversations and the AI judge that analyses them afterwards. **Global** lets Famulor's own routing choose; pinning **EU** or **US** keeps that processing inside the chosen zone and narrows the model catalog to what is offered there, so an assistant can only be set to a model available in the region. This is the workspace-level control behind the processing-location commitments described in [Trust Center](/support/trust-center). Pinning either region can raise the cost of that AI usage compared with Global routing.

The **Beta features** toggle also lives on this page. Several capabilities referenced elsewhere in these docs — connected-app triggers in [Automations](/automations/overview), [WhatsApp Call](/telephony/whatsapp-voice), and the Beta channel connectors, among others — stay hidden until an owner or admin turns it on. Beta features can be unstable and change, and some process additional conversation context and add AI usage, so review each one before enabling it.

## Roles and team management

Open **Settings → Workspace → Team** in the workspace where the person should work. Invitations and roles apply only to that workspace, and a person can hold a different role in each workspace they belong to — owner in one, member or viewer in another. The Team panel always shows the active workspace's name to help prevent inviting someone into the wrong account.

### Roles

| Role        | Access                                                                                                                                                                                            |
| ----------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **owner**   | Full access, including team, billing, and workspace settings. The account that created the workspace holds this role; it can't be handed to anyone else, changed, or removed from the Team panel. |
| **admin**   | Full access, including team, billing, and workspace settings.                                                                                                                                     |
| **member**  | Full access to the workspace features assigned to them.                                                                                                                                           |
| **viewer**  | Read-only — can't make any changes.                                                                                                                                                               |
| **billing** | Read-only, plus managing Plan and Balance. The sidebar shrinks to the dashboard, Usage, and a Settings page reduced to Preferences, Plan, and Balance.                                            |

### Inviting a member

Owners and admins add a member one of two ways:

* **Invite by email** — sends an email with a link to set a password. An existing account is added directly and notified by email instead of getting an invite link.
* **Create with a password** — set a name and an initial password (at least 8 characters) yourself, with no email round-trip.

Both modes ask for the new member's role up front — any role except owner — and show that role's description as you pick it. A member added by email keeps an **Invited** badge in the list until they sign in for the first time. Once a workspace reaches its member limit, **Invite member** is replaced by a link to **Settings → Plan** for more capacity.

### Managing a member

From a member's row, owners and admins can:

* **Change their role** — pick a new one from the dropdown; it applies immediately.
* **Send a login link** — emails a single-use link that signs the member in without a password and expires shortly after, useful when someone is locked out.
* **Remove them** — drops their access to this workspace only, without affecting any other workspace they belong to, and leaves their Famulor account itself intact.

The owner's row carries none of these controls; every other member can have their role changed or be removed.

## REST API

List the workspaces visible to the credential:

```bash theme={null}
curl https://YOUR_DOMAIN/api/v1/workspaces \
  -H "Authorization: Bearer fam_..."
```

Create a workspace with a user-authorised credential:

```bash theme={null}
curl -X POST https://YOUR_DOMAIN/api/v1/workspaces \
  -H "Authorization: Bearer fam_..." \
  -H "Content-Type: application/json" \
  -d '{"name":"Acme Corp — EU"}'
```

Use `settings:read` to list workspaces and `settings:write` to create one. A workspace-only service credential can list its own workspace but cannot create a workspace on behalf of a person.

Create a dedicated API key for a workspace returned by the list endpoint:

```bash theme={null}
curl -X POST https://YOUR_DOMAIN/api/v1/workspaces/WORKSPACE_ID/api-keys \
  -H "Authorization: Bearer fam_..." \
  -H "Content-Type: application/json" \
  -d '{
    "name":"EU reporting",
    "scopes":["calls:read","leads:read"],
    "expires_in_days":90
  }'
```

This operation requires a user-authorised credential with `settings:write`. The credential's user must currently be an owner or admin in the selected workspace, and the workspace must belong to the same brand as the credential. It works for regular multi-workspace accounts and does not require white-label access. Members, viewers, billing users, and workspace-only service credentials cannot use it.

The new key is permanently bound to the selected workspace. Its scopes cannot exceed the calling credential, and it cannot outlive a calling credential that already has an expiry. The plaintext key appears only in the successful response, so store it immediately and do not retry a successful request automatically. A newly created workspace may receive its key before plan activation, but normal API calls with that key remain plan-gated.

Workspace-capacity and extra-member add-ons have separate jobs: workspace capacity controls creating additional workspaces, while member capacity controls invitations. Neither adds another requirement after a user already has an owner/admin role in the target workspace.

## MCP

* `list_workspaces` lists the workspaces visible to the connected user.
* `create_workspace` creates a workspace when the connected user has remaining allowance.
* `create_workspace_api_key` creates a dedicated key for a visible workspace where the connected user is an owner or admin.

These operations follow the same permissions and plan rules as the REST API. Inviting, removing, or changing a member's role has no REST or MCP equivalent — team management is UI-only.