Skip to main content
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.
  • 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.
  • 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. 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.
  • 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.
  • 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.

​
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

​
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.