> For the complete documentation index, see [llms.txt](https://docs.ninox.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ninox.com/builder-hub/manage-your-organization-and-workspace/organize-your-workspace/manage-workspace-access.md).

# Manage workspace access

Workspace access controls what someone can do inside one workspace.

Workspace access is separate from organization access. You can make someone an organization admin and still limit their access in a specific workspace. For organization-wide access, see [Manage organization access](/builder-hub/manage-your-organization-and-workspace/manage-your-organization/manage-organization-access.md).

Give each member one default workspace role. That role defines their baseline access.

* **Admin**: Full access to the workspace.
* **Editor**: Can read, create, edit, and delete data.
* **Viewer**: Can read and export data, but cannot create, edit, or delete it.
* **None**: No default workspace role. Use this when access should come only from custom roles.

Use custom roles when the default role is too broad. Create them at the organization level and reuse them across workspaces in the same organization.

{% hint style="info" %}
A user can have custom roles with or without a default workspace role.
{% endhint %}

In Builder mode, you can apply permissions at three levels:

* **App level**: Control which roles can access one app. In **App settings**, use **Allow access to** to limit access to selected workspace roles or custom roles.
* **Table level**: Control who can read, edit, create, and delete records in a table.
* **Field level**: Control who can read specific fields, such as email addresses or phone numbers.

This lets you control access at the right level. For example, you can limit one app to selected roles, let a support role view a table, and let only a delivery role see the **Address** field.

A custom role only takes effect after you assign it in a workspace and use it in app, table, or field permissions. If you do not use a custom role in permissions, the member's default workspace role decides their access.

Custom roles can also narrow access. For example, someone can be an **Editor** in the workspace but still be blocked from editing one table unless they also have the required custom role.

{% hint style="info" %}
**Admin** does not appear in restricted permission pickers. Workspace admins always keep full access.
{% endhint %}

### Add and review members

Use the **Workspace users & roles** screen to review everyone who can access the workspace.

You can search by email, filter by status, and review each user's role, joined or invited state, verification, and status.

{% stepper %}
{% step %}

#### Open workspace users

If you are not already on the settings screen, click the gear icon **Settings** in the main navigation.

Under **WORKSPACE**, select **Workspace users**.
{% endstep %}

{% step %}

#### Invite a user

Select **Invite users** and enter one or more email addresses.
{% endstep %}

{% step %}

#### Choose the workspace role

Select one default workspace role:

* **None**
* **Admin**
* **Editor**
* **Viewer**
  {% endstep %}

{% step %}

#### Add custom roles if needed

Select one or more custom roles to add more specific access rules.

To create a new custom role, start typing in **Search custom role**. If the role does not exist yet, select **Create "..." as custom role**.

After you create it, the new role appears in the custom roles list and is selected in the same dialog.

{% hint style="warning" %}
If you assign only a custom role, make sure that role is already used in app, table, or field permissions.

If no permissions are configured for that custom role yet, the invited user can join the workspace but will land on a blank screen with no access.
{% endhint %}
{% endstep %}

{% step %}

#### Choose the invitation language

Select the language for the invitation email.
{% endstep %}

{% step %}

#### Send the invite

The user appears in the workspace member list. The invite stays pending until they accept it.
{% endstep %}
{% endstepper %}

Keep in mind:

* If the invited user is not already part of the organization, inviting them to the workspace also adds them to the organization as a **Member**.
* If you assign or change roles for an invited user, the change only takes effect after they accept the invitation and join the organization.

Use the member list to review invited and active users, check their status, and update access when needed.

### Change workspace roles

Change a user's default workspace role from the member list when their baseline access changes.

Use this when someone needs broader access, read-only access, or no default role. If you only need to allow or restrict one app, table, or field, keep the default role and adjust custom roles or permissions instead.

{% stepper %}
{% step %}

#### Open workspace users

If you are not already on the settings screen, click the gear icon **Settings** in the main navigation.

Under **WORKSPACE**, select **Workspace users**.
{% endstep %}

{% step %}

#### Find the user

Use search or filters to find the invited or active user.
{% endstep %}

{% step %}

#### Change the default role

In the user's row, select the workspace role and choose **Admin**, **Editor**, **Viewer**, or **None**.
{% endstep %}

{% step %}

#### Review custom roles if needed

Keep or update custom roles if the user also needs more specific app, table, or field access.
{% endstep %}
{% endstepper %}

Keep in mind:

* Changes for active users apply right away.
* Changes for invited users apply after they accept the invitation and join the organization.
* **None** removes default workspace access. Any remaining access must come from custom roles used in permissions.
* If a user has only custom roles and those roles are not used in any app, table, or field permissions yet, they will see a blank screen with no access.

### Create and assign custom roles

Create workspace custom roles at the organization level and reuse them across workspaces in the same organization.

The role list shows each role's name, description, and creation date.

{% stepper %}
{% step %}

#### Open workspace custom role management

If you are not already on the settings screen, click the gear icon **Settings** in the main navigation.

Under **ORGANIZATION**, select **Users & roles**.

Select the **Workspace custom role management** tab.
{% endstep %}

{% step %}

#### Create a custom role

Select **Create role**, enter a role name, and add an optional description.
{% endstep %}

{% step %}

#### Reuse the role in workspaces

After you create a custom role, workspace admins can assign it while inviting or editing a workspace user.

They can then use it for app, table, and field permissions.

To create a new custom role while inviting someone, start typing in **Search custom role**. If the role does not exist yet, select **Create "..." as custom role**.
{% endstep %}

{% step %}

#### Delete the role if you no longer need it

Select the role and choose **Delete role(s)**.

{% hint style="warning" %}
Deleting a custom role also removes its assignments and related permission associations in workspaces. This includes app, table, and field permissions. This action cannot be undone.
{% endhint %}
{% endstep %}
{% endstepper %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.ninox.com/builder-hub/manage-your-organization-and-workspace/organize-your-workspace/manage-workspace-access.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.