Roles & Permissions
Audience: End User, Admin Page Type: Concept Summary: Roles control what you can see and do in COS. Permissions depend on your role, your org unit scope, and item ownership.
What a role affects
In COS, your role typically affects:
- Menu visibility (which modules/pages appear)
- Actions you can perform (create/edit/approve/manage users)
- Scope (your own items vs your unit vs the whole organization)
Where permissions come from
When you try to do something in COS, the system checks a combination of:
- Role: your baseline access level
- Org scope: which unit(s) you're responsible for
- Ownership / assignment: whether you own the item or are assigned to it
- Workflow state: some actions can be restricted while an item is pending approval or locked
Role layers
COS uses a multi-layer authorization model. The table below explains what each layer means:
| Layer | Description | Example Roles |
|---|---|---|
| Platform | Full system administration | Super Admin |
| Holding / Group | Visibility across all companies in a group | Group Admin |
| Company (Tenant) | Your permission level within a single company | Admin, Strategy Manager, Team Lead, Member |
| Org Unit | Your position in the org chart | Team Lead, Member |
Note: A user can have permissions in multiple layers at once. For example, a Group Admin can also be an Admin within a specific company.
Typical roles
| Role | What they can do | Scope |
|---|---|---|
| Member | Reads OKRs, KPIs and strategy data of the whole company; updates only the progress (and initiative status) of the key results and initiatives they own or contribute to, and the KPIs they are responsible for | Read: company · Write: own items |
| Team Lead | Reads company-wide; creates and edits OKRs, findings and analyses in the units they lead and their sub-units; sees person performance only for that subtree | Read: company · Write: led subtree |
| Strategy Manager | Full access to every business module (strategy cycles, focus areas, analyses, OKRs, KPIs, reports); manages users up to their own level and the org structure. No access to company administration areas (see below) | Entire company |
| Admin | Manages users, roles, org structure, and system settings | Entire company |
| Group Admin | Views and manages business data across all companies in their group; can manage users | All companies in group |
| Super Admin | Full platform-level permissions | Entire system |
Access matrix (summary)
| Capability | Super Admin | Group Admin | Admin | Strategy Manager | Team Lead | Member |
|---|---|---|---|---|---|---|
| OKR & KPI | ✅ | ✅ | ✅ | ✅ | Read company · write led subtree | Read company · progress of own items |
| Person performance reports | ✅ | ✅ | ✅ | ✅ | Led subtree | Only themselves |
| Strategy modules (SWOT, BSC, PESTLE, etc.) | ✅ | ✅ | ✅ | ✅ | See below* | View only |
| User management | ✅ | ✅ | ✅ | Up to Strategy Manager | — | — |
| System / tenant settings | ✅ | ✅ | ✅ | — | — | — |
| Platform administration | ✅ | — | — | — | — | — |
| Group management | ✅ | ✅ (create group: Super Admin only) | — | — | — | — |
| Approvals (OKR, plans, etc.) | ✅ | ✅ | ✅ | ✅ | Ancestor units | — |
| Dashboard view | Platform | Admin | Admin | Strategy | Team Lead | Member |
KPI measurement authority comes from the KPI, not the role. Measurements on a KPI can be entered by the KPI's responsible (even a Member), the leaders of the owner unit and its parent units, Company Admin, Strategy Manager, Holding Admin in tenants of their group, and Super Admin. Report edit permission does not grant measurement authority. KPI creation: Unit Leaders in their unit and its sub-units; Members cannot create KPIs. See KPI Tracking.
Team Lead strategy access: Create/edit/delete depends on the effective modules and, where required,
unit_level_strategy. A preset name alone does not grant access.
Strategy Manager and administration areas
From 0.5.44 the Strategy Manager cannot reach these company administration areas, neither from the menu nor through the API (403):
- Company profile and status (viewing allowed, changing blocked)
- API keys
- Creating, editing, deleting and testing integration endpoints (viewing endpoints and KPI bindings stays allowed)
- Menu configuration
- AI provider settings (company and group)
- Admin dashboard, AI usage and analytics screens (including the AI assistant's admin dashboard tool)
User management (up to their own level), org structure, the success criteria template and every business module stay open. These areas are unchanged for Admin, Group Admin and Super Admin.
User and role management rules
- Up to your own level: level order is Member < Team Lead < Strategy Manager < Admin < Group Admin < Super Admin. A Strategy Manager assigns and invites up to Strategy Manager, an Admin up to Admin, a Group Admin up to Group Admin. Group Admin and Super Admin roles are never assigned from the user list.
- Not yourself: nobody changes their own role or suspends or removes themselves. A Group Admin who is not the owner may leave their group.
- Last admin protection: the company's last active Admin, the group's last active Group Admin, and the platform's last active Super Admin cannot be demoted, suspended, or removed.
- Protected targets: Admins and Strategy Managers cannot act on the Group Admin of the company's group or on a Super Admin. Only a Super Admin changes the group owner.
- Suspend vs. remove: suspending a membership is reversible and keeps role and ownerships; permanent removal deletes the membership.
- Name: only the user changes their own name.
- Groups: Group Admins are added only by invitation; a group is created only at sign-up or by a Super Admin; only the owner or a Super Admin transfers ownership or deletes a group.
Details: User Management, Group Management.
Strategy module permission details
Module access comes from effective entitlements. The following scope applies when the relevant module/feature is enabled and the role's permission rows allow the action:
| Area | Team Lead | Member |
|---|---|---|
| SWOT, PESTLE, Porter, BCG, status reports, VRIO and product analyses | Read across the company; with unit_level_strategy, create/edit/delete within the led subtree | Read across the company |
| DMA and Excellence | Manage/respond within unit and task scope | Complete assigned response tasks; view authorized results |
| Findings | Create/edit/close/move to SWOT within the led subtree; company-level only for the root leader, no writes in a closed cycle | View |
| Products, mission/vision, planning periods and focus areas | View; writes require the relevant record and role authority | View |
| Legacy BSC reports | Read-only | Read-only |
| AI Assistant | Use within own record access | Use within own record access |
Confidential OKRs apply owner/contributor and leader/administrator rules separately. An enabled module does not expand that record scope. Company or installation read-only restrictions also limit otherwise authorized writes.
How Team Lead is determined
The Team Lead role is stored directly in the database as TEAM_LEAD. When a user is assigned as a unit leader in the org chart, the system automatically upgrades their membership role to TEAM_LEAD.
- Company leader: If you lead the root (company) unit, you gain company-wide visibility
- Division/team leader: You can manage your unit and all sub-units (recursively to the deepest level)
- Org page access: TEAM_LEAD and MEMBER users can view the org chart in read-only mode. TEAM_LEAD can add members only within their own unit subtree, and only people of their own company (or people not yet in any unit). TEAM_LEAD sets leaders only in strict sub-units of the units they lead: the leader of a unit they lead is changed by a parent-unit leader or an administrator
Org unit scope explained
Every user is assigned to one or more Organization Units in the org chart. Their scope — which records they can see and act on — follows that assignment.
| Scenario | Scope |
|---|---|
| Member of Unit A | Reads OKR/KPI/strategy data of the whole company (every company that contains one of their units); writes only progress of own key results and initiatives; org-unit bound writes only in Unit A |
| Team Lead of Unit A | Reads the whole company; writes (OKRs, findings, analyses, members) in Unit A and all sub-units recursively |
| Root unit leader (company top) | Writes company-wide, including company-level findings and analyses |
| Strategy Manager | Sees the entire company regardless of unit assignment |
| Admin | Sees the entire company |
Ancestor unit approvals: When an OKR from Unit A is pending approval, the Team Lead of the parent (ancestor) unit can act as approver — in addition to Admins and Strategy Managers.
Your unit assignment is set by an Admin. If your scope seems incorrect, ask an Admin to verify your org unit assignment.
Common permission patterns (practical)
- If you can't see a menu, you likely don't have permission for that module.
- If you can see but can't edit, you may be outside the scope (different unit) or the item may be in an approval/locked state.
- Approvals can be configured per organization and per workflow.
Read-Only Mode
Some conditions restrict a user to read-only access even when they normally have edit rights:
| Trigger | Effect |
|---|---|
| On-prem license grace expired | The installation becomes read-only; normal record changes are rejected until a new license is installed |
| OKR Cycle closed | Once a cycle is closed, its OKRs, KRs, and measurements are frozen |
| Item in approval workflow | Items awaiting approval are locked until the approval resolves |
| Confidential item | A confidential objective, key result or initiative is visible only to administrators/strategy managers, the leaders of its unit and of the parent units, and its owners and contributors (also the owners/contributors of an item under it, or of the objective above it). Being assigned to the unit alone does not reveal it |
| Company suspended | The whole company is read-only for its users, Admins included (AI chat, notifications, and personal dashboards too). Super Admins and the group's Group Admin can still make changes. Only they can change the company status |
Read-Only Mode is shown in the UI — action buttons disappear or appear disabled, and a notice typically explains the reason.
Module access and effective entitlements
Access combines module entitlement + role permission + menu availability + record scope. Preset names such as Free/Pro/Enterprise are form shortcuts, not a fixed access matrix.
- SaaS applies the group's effective entitlement set and catalog. The Group Admin views the set under Settings → Plan & Subscription; the Super Admin manages Entitlement Sets.
- On-prem installations use the signed license. A missing module shows Add to your license; changing a database plan does not grant access.
- AI is available to every entitlement set. In SaaS, COS-model messages/research consume the monthly group pool; company/group providers do not consume it. Record permissions and applicable rate/retention limits still apply.
- A known URL does not grant access when the module is unavailable, the company menu is hidden, or the user lacks permission.
See Entitlement Sets, License and Modules, and Menu Settings.
What to do if something is missing
- Check whether you're in the correct workspace/tenant.
- Ask an Admin to confirm:
- your role
- your org unit assignment
- any approval workflow restrictions
Role Guide (in-app reference page)
COS includes a built-in Role Guide page accessible to all authenticated users at /account/roles-guide ("Role Guide" in the left menu).
It shows:
- Your current role and a brief description
- Cards for all 6 roles with a layer/scope summary, and the role architecture panel
- The Permission Matrix: module × role with view/create/edit/delete (V/C/U/D) icons. From 0.5.44 the matrix is no longer hand-written; it is generated from the permission rows the API authorization check reads, so it always shows the actual access. A dashed icon (e.g. C*) means limited access (unit scope, conditions or part of the module). If the matrix cannot be loaded, an error message with a "Retry" button is shown.
- Below the matrix, the rules applied on top of the permission rows (unit scope, ownership, user management ceiling and similar)
- Concept explanations: Org Unit Scope, Module Access (effective entitlements), Read-Only Mode, Approval Workflow
The matrix contains no company data; a Super Admin without a selected company and a Group Admin whose group has no company can open it too.
All authenticated users can access it regardless of role.