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

# Company settings, users and roles

> Settings is where a company manages its people and its policies.

The company itself: who belongs to it, which role each member holds and what that role allows,
the sign-in policy, the agreements the company has accepted, and the company-wide defaults. It
sits in the **Settings** sidebar group as **General** (`/settings/general`), **Security**
(`/settings/security`), **Privacy & Security** (`/settings/privacy-security`), **Users**
(`/settings/users`) and **Roles** (`/settings/roles`). The **UI Settings** group holds two
per-person preferences, **Look & Feel** (`/settings/look-and-feel`) and **Sidebar Config**
(`/settings/sidebar`). Creating a company happens on the company picker (`/select-company`).

## What it does

* **Companies.** Any signed-in user can create a company with a name and a unique slug
  (`createCompany`); the creator becomes its Admin and the company gets a Free subscription in
  the same transaction. `myCompanies` lists every company the caller has a membership row in;
  `company(companyId)` returns only the caller's active company, whatever id is passed. `me`
  returns the caller's profile, `currentRole` and `abilities` (the class-scoped abilities of the
  active membership).
* **Members and invitations.** The Users page lists active members, removed members and pending
  invitations together (`companyMembers`), each with role, status, joined date and last login.
  `MembershipStatus` is `ACTIVE`, `INVITED` or `DEACTIVATED`. A user has at most one membership
  row per company (unique user and company pair); removing a member sets the row inactive, and
  re-inviting reactivates the same row.
* **Inviting** (`inviteUserToCompany(email, roleId)`). The email is trimmed and lowercased. If a
  user with that email already exists, they are added (or re-activated) at once with the chosen
  role. Otherwise a pending invitation is stored for 30 days; it is accepted automatically the
  next time someone signs in with that email; a sign-in whose email is not verified leaves it
  pending. No
  invitation email is sent by the server. An existing active member or an already pending
  invitation for the same email is refused.
* **Cancel, remove, change role.** `cancelInvitation` cancels a pending invitation only.
  `removeUserFromCompany` deactivates the membership and cancels any pending invitation for the
  same email, so the person is not re-added on the next sign-in; you cannot remove yourself.
  `changeUserRole` sets another role; the last active Admin cannot demote themselves.
* **Roles.** Three roles: **Viewer**, **Editor**, **Admin**. A stored role becomes a rank by one
  rule: a role whose permissions contain `all` is Admin; a role named `viewer` (any case), or a
  membership with no role, is Viewer; any other role is Editor. Roles are fixed and global; a
  company cannot define its own. The Roles page is a read-only matrix of the class-scoped
  abilities each role holds, read from `abilityCatalog("class")`, with your own role marked.
* **What each role can do.** Class-scoped abilities go by minimum role; Admin holds everything
  Editor holds. Object-scoped abilities (`agent.chat`, `workflow.view`, `workflow.execute`) are
  not role-based: each agent or workflow's Access table decides them, an object with no grants
  is open to every member, and Admins and Editors are subject to those grants too. The table
  below lists every class-scoped ability.

| Ability | Minimum role | What it allows |
| - | - | - |
| (membership) | Viewer | Read company data, view agreements, edit the operational settings below |
| `agent.manage` | Editor | Create, edit and delete agents and routers, configure sandboxes, edit agent Access |
| `workflow.manage` | Editor | Create, edit and delete workflows and webhooks, edit workflow Access |
| `integration.manage` | Editor | Connect, verify and disconnect GitHub and Jira; set up an agent's Slack app |
| `environment.manage` | Editor | Create, edit, duplicate and delete environments, reveal their secrets |
| `tool.manage` | Editor | Create, edit, test and delete the company's tools |
| `content.manage` | Editor | Approve and reject content sources, promote content to agent knowledge |
| `executor.manage` | Editor | Reclaim stale cloud worker images |
| `sandbox.delete` | Admin | Delete a sandboxed agent and its cloud compute |
| `integration.manage_providers` | Admin | Create, edit and test provider integrations and credentials |
| `environment.manage_dockerfile` | Admin | Give an environment a custom Dockerfile on Olyros Cloud |
| `tool.manage_restricted` | Admin | Manage tools that call out of the platform (HTTP, MCP) |
| `tool.audit` | Admin | Read the tool call audit log |
| `skill.manage` | Admin | Create, edit, upload and delete skills, bind them, revoke tool consents |
| `mcp.manage` | Admin | Add, edit and remove MCP servers, bind them, see connections |
| `oho.manage` | Admin | Allow an OHO host to run skill code |
| `user.manage` | Admin | Invite and remove members, change roles |
| `slack.manage` | Admin | Link and remove Slack users, manage Slack groups, run access audits |
| `billing.manage` | Admin | Change the plan, top up credits, open the billing portal |
| `company.manage` | Admin | SSO policy, Olyros Cloud toggle, agreements, skill-code settings |

* **Security: Google sign-in policy** (`updateCompanySsoPolicy`). When **Require Google sign-in**
  is on, every member must sign in with a Google account; with **Allowed email domains** set,
  the verified email must be on one of them. Domains are stored trimmed, lowercased, without
  `@`, and a pasted email keeps only its domain; matching is exact, so `acme.com` does not admit
  `eng.acme.com`. With the switch on and no domains, any Google account is admitted, and the
  page warns about it. A member who fails the policy is refused on every request with
  `SSO_POLICY_VIOLATION`. Two guards stop a lockout: if the saving admin would fail the new
  policy the save returns `SSO_SELF_LOCKOUT_WARNING` and needs `confirmLockout`, and a policy no
  active admin could pass is refused outright with `SSO_NO_COMPLIANT_ADMIN`. The same page has an
  **Auditing** section (Admin) that exports Slack user access; see [Slack](https://user-docs.olyrosstudios.com/slack.md).
* **Privacy & Security: agreements.** One agreement type exists, `hipaa_baa` (the Olyros
  Platform HIPAA Business Associate Addendum, version `1.0`). Any member can read it
  (`agreementDocument`) and see who accepted it and when (`agreementAcceptance`). An Admin
  accepts it (`acceptAgreement(agreementType, version)`); each acceptance is a new row recording
  the admin's email. A new published version marks the old acceptance stale and asks for
  re-acceptance; draft text can be previewed but not accepted.
* **General.** Three sections. **Transcription**: the Whisper speech-to-text model (`tiny`,
  `base`, `small`, `medium`, `large-v3`, or the OHO default) and a daily spend cap in USD.
  **Execution**: the default "Runs on" backend for agents without their own pin
  (`setCompanyDefaultBackend`), described in [OHO and environments](https://user-docs.olyrosstudios.com/oho-and-environments.md).
  **Skill Code** (Admin): the tool bridge switch, running skill code on the company's OHOs, the
  default order (`cloud`, `oho,cloud`, `oho`, `cloud,oho`), and which OHOs may run skill code;
  see [Skills](https://user-docs.olyrosstudios.com/skills.md).
* **Memory settings.** The embedding and extraction integration and model, memory extraction
  and the per-agent memory cap are edited on Agents > Memory (`/settings/memory`) through the
  same `updateCompanySettings`; see [Agents](https://user-docs.olyrosstudios.com/agents.md).
* **Look & Feel** (per person, this browser). Eight themes: Sky Light (default), Forest Light,
  Electric Lime, Berry Blast, Midnight Dark, Deep Ocean Dark, Cyberpunk Neon, Synthwave Sunset;
  three densities: `compact`, `default`, `comfortable`. Both are saved in browser local storage,
  not on the server, so they do not follow you to another browser and are not shared with the
  company.
* **Sidebar Config** (per person, this browser). Up to 5 named sidebar profiles, each a JSON
  description of the sidebar validated against a schema, plus the read-only System Default.
  Profiles and the active choice are saved in browser local storage only.

## Who can use it

* **Any signed-in user:** create a company, list their companies, read `me`.
* **Any company member (Viewer and up):** see the member list, the Roles page, the company
  settings and agreements; save the transcription settings, the memory settings and the default
  backend, because `updateCompanySettings` and `setCompanyDefaultBackend` check membership only.
* **Company admin** (`user.manage`): invite, cancel invitations, remove members, change roles.
* **Company admin** (`company.manage`): the SSO policy, accepting agreements, and the three
  skill-code fields of `updateCompanySettings` (`toolBridgeAllowed`,
  `ohoSkillExecutionEnabled`, `skillExecutionOrder`). Allowing a single OHO needs `oho.manage`.
* Pages render read-only for members without the ability, from `me.abilities`.
* There is no per-feature plan gating. The seat count is checked against the plan when an
  invitation is sent; see [Billing and usage](https://user-docs.olyrosstudios.com/billing-and-usage.md).

## How to configure it

1. **Create a company:** company picker (`/select-company`) -> Create New Company, name and slug
   -> `createCompany`.
2. **Invite a member:** Settings > Users (`/settings/users`) -> Invite User, email and role (the
   dialog defaults to Viewer) -> `inviteUserToCompany`. The person signs in with that email to
   join.
3. **Cancel an invitation:** Users -> row with status Invited -> Cancel -> `cancelInvitation`.
4. **Change a role or remove a member:** Users -> active row -> Change Role (`changeUserRole`) or
   Remove (`removeUserFromCompany`). Your own row has no actions.
5. **See what each role can do:** Settings > Roles (`/settings/roles`), read-only
   (`abilityCatalog`).
6. **Require Google sign-in:** Settings > Security (`/settings/security`) -> Require Google
   sign-in for all members -> add domains (Enter or comma) -> Save changes ->
   `updateCompanySsoPolicy`. Confirm the lockout dialog if it appears.
7. **Accept the HIPAA BAA:** Settings > Privacy & Security (`/settings/privacy-security`) ->
   Review agreement -> accept in the dialog -> `acceptAgreement`.
8. **Transcription defaults:** Settings > General (`/settings/general`) -> STT Model and Daily
   Spend Cap (USD) -> Save Settings -> `updateCompanySettings`.
9. **Default backend:** General -> Default "Runs on" (saves on change) ->
   `setCompanyDefaultBackend`.
10. **Skill code:** General -> Skill Code switches and Default order (each saves on change) ->
    `updateCompanySettings`; per-OHO switch -> `setOhoSkillExecutionAllowed`.
11. **Theme and density:** UI Settings > Look & Feel (`/settings/look-and-feel`) -> pick a
    density and a theme card. Applies at once, browser only.
12. **Sidebar profile:** UI Settings > Sidebar Config (`/settings/sidebar`) -> Create New
    Profile, edit the JSON, Save -> Use This Profile. Browser only.

Validation that rejects input: `maxMemoriesPerAgent` below 1; `whisperDailySpendCap` below 0;
an STT model outside the list; `tempFileMaxSizeMb` outside 1 to 50; an unknown
`skillExecutionOrder`; a domain list that normalizes to nothing.

## Limits and defaults

| Setting | Default | Where enforced |
| - | - | - |
| Invitation lifetime | 30 days | `inviteUserToCompany`; expired at sign-in |
| Memberships per user per company | 1 | unique index on the user and company pair |
| Seats | plan's `max_seats` (Free fallback 1); refusal follows the billing enforcement mode | billing structural check on invite |
| `require_google_sso` | off | `CompanySettings` |
| `allowed_email_domains` | none (any Google account) | `CompanySettings` |
| `whisper_daily_spend_cap` | 10.0 USD; 0 disables the cap | `CompanySettings`, General page |
| `stt_preferred_model` | none (OHO default) | `CompanySettings` |
| `temp_file_max_size_mb` | 8 (1 to 50) | `updateCompanySettings` |
| `memory_extraction_enabled` | on | `CompanySettings` |
| `max_memories_per_agent` | 10000 (min 1) | `updateCompanySettings` |
| `rag_reranking_enabled` | on | `CompanySettings` |
| `tool_bridge_allowed` | on | `CompanySettings` |
| `oho_skill_execution_enabled` | off | `CompanySettings` |
| `skill_execution_order` | `cloud` | `CompanySettings` |
| `default_backend_id` | none | `setCompanyDefaultBackend` |
| Sidebar profiles | 5 per browser | sidebar service |
| Theme / density | Sky Light / `default` | browser local storage |

## What it emits

* Audit events when an admin changes `toolBridgeAllowed` (`skill.tool_bridge_allowed.set`),
  `ohoSkillExecutionEnabled` (`skill.oho_execution.set`) or `skillExecutionOrder`
  (`skill.execution_order.set`), each with the old and new value.
* Turning on OHO skill execution starts warming the runtime image on the company's OHOs.
* An append-only agreement acceptance row per acceptance (type, version, admin, email, time).
* Invitation rows with status `pending`, `accepted`, `expired` or `cancelled`.
* Membership, role, SSO policy and transcription changes write no audit event.

## Known gaps

* No invitation email is sent; the admin has to tell the person to sign in with that email.
* Any member, Viewer included, can save transcription, memory and default-backend settings; only
  the skill-code fields are admin-only on the server.
* `ragRerankingEnabled` and `tempFileMaxSizeMb` have no control in the UI; only the API sets them.
* Roles are fixed; there are no custom roles or per-company permission edits.
* Only Google is supported as a required sign-in provider; no SAML or other identity provider.
* Membership changes, role changes and SSO policy saves are not audited.
* Look & Feel and sidebar profiles are per browser; they do not sync across devices.
* There is no company rename, slug change or company delete in this area.

## Customer-safe summary

Settings is where a company manages its people and its policies. Admins invite colleagues by
email with a role (Viewer, Editor or Admin), change roles and remove members, and the Roles page
shows exactly what each role may do; access to individual agents and workflows is set on each
one. Admins can require everyone to sign in with Google, limited to the company's own email
domains, with safeguards that stop them locking themselves or every admin out. The Privacy &
Security page lets an admin review and accept the HIPAA Business Associate Addendum, and every
member can see when it was accepted and by whom. General settings hold company-wide defaults for
transcription, where agents run and where skill code runs. Theme, density and sidebar layout are
personal choices saved in your browser.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.