---
question: Which workspace features can each role open?
kind: guide
---

# Organization settings

Organization Settings opens from the account menu. Nexus shows it to owners and admins of the current workspace (`settings.organization`, decided in the browser from the workspace role, not from the Roles matrix). It goes to `/organizations`. One organization redirects to `/organizations/{id}/settings`. The header is the organization name. The nav heading is Organization Settings.

![Organization Settings on Roles](/abi/Screenshot_Organization_Settings.png)

*Organization Settings, Roles. Viewer, Member, Admin, and Owner, and the workspace features each one can open. Owner is fixed.*

## What you can set

| Item | Who sees it | What it is |
|---|---|---|
| General | Anyone who can open organization settings | Name, saved with `PATCH /api/organizations/{id}`. Only an organization owner or admin can save. Domain is read-only. |
| Branding | Owner or admin | Logos, colors, the login page, and the default theme. The page subtitle says that. |
| Workspaces | Anyone who can open organization settings | The workspaces of this organization. Click a row to open its settings. An owner or admin can [create one](/user-guide/platform/create-a-workspace), and becomes its owner. |
| Users | Owner or admin | People with access to the organization. See [Invite an organization member](/user-guide/platform/invite-an-organization-member). |
| Roles | Owner or admin | Which workspace features each workspace role can use. |

Domains, Servers, Services, and Billing are not in that nav. The routes exist and are marked hidden.

## Organization roles

Organization membership is Owner, Admin, or Member. There is no organization viewer. The labels are on Users. An invite offers Member or Admin. The owner comes from the config (`owner_email`) only; `organizations[].members` in the config is deprecated and ignored.

An owner or admin can change another person's organization role. A member can open General and Workspaces. Branding, Users, and Roles stay off that nav.

## Workspace features by role

Roles is not the organization membership list. The page says: define which workspace features each role can access. The columns are Viewer, Member, Admin, and Owner. Those are workspace roles. Owner access is fixed. Until a save writes an organization overlay, the matrix is the deployment baseline in `nexus_config.feature_flags`.

The two generated configs set different baselines:

- **`config.yaml`** (`abi dev up`) sets no `feature_flags`, so the built-in default applies. Viewer and Member have Chat, Datasets, Documents, Files, Maps, Sheets, Skills, and Slides. Admin and Owner also have Agents, Apps, Graph, Marketplace, Ontology, Search, and Settings.
- **`config.local.yaml`** (the Docker stack) enables Chat, Files, Agents, Apps, Marketplace, Search, Ontology, Graph and Settings (and Code with `--with-coding`). Viewer and Member get Chat and Files only. Maps, Datasets, Slides, Documents, Sheets and Skills are off for everyone.

Skills is in the matrix. The dock has no Skills icon. The Settings line does not hide the dock's Settings: Nexus shows that to workspace owners and admins whatever the matrix says.

Who holds a workspace role is [Workspace settings](/user-guide/platform/workspace-settings), on Members. Super admin is not a column here. That flag opens [Platform settings](/user-guide/platform/platform-settings).
