Roles and teams
Every person in a MopokeHQ organisation has a role. Teams, when you use them, narrow which projects each member sees and give each team a Lead who can close its work.
| Role | Sees | Decides |
|---|---|---|
| Owner | Every project and every organisation page | Everything, including closing a P1 or a critical finding without a fix. Only owners make other owners and close the organisation. |
| Admin | Every project and every organisation page | Everything an owner does, except those owner-only actions. |
| Viewer | Every project and every organisation page, evidence packs included | Nothing: read-only. No acknowledging, triage, upgrade requests or Ask Lilly. For auditors and managers who only need to look. |
| Member | Without teams, every project. With teams, their teams’ projects. | See below. |
Owners and admins invite people as members, admins or Viewers, and change roles on the Members page. Admins cannot change an owner.
What a member may do
Section titled “What a member may do”| Without teams | With teams: Developer | With teams: Lead | |
|---|---|---|---|
| Acknowledge a P1, request upgrade merge requests, Ask Lilly | Yes | Yes, on their projects | Yes, on their projects |
| Confirm a fix that is waiting to be confirmed | No | No | Yes, when they lead every project it touches |
| P2 and P3 decisions: not affected, accepted risk, dismiss a finding, confirm or keep Lilly’s suggestion, reopen | No | No | Yes, when they lead every project it touches |
| Close a P1 or a critical finding without a fix | No | No | No |
Without teams, confirming fixes and P2 and P3 decisions are for owners and admins. With teams, a decision that also touches a project the Lead doesn’t lead is refused with “This also affects projects you don’t lead. An owner or admin decides it.”
Acknowledging needs only one visible project: it means someone is on it, and it stops the escalation for everyone.
Teams are a paid feature. To switch them on for your organisation, talk to us. Once they are on, a member sees only their teams’ projects, so create teams and add people straight away.
- A team has people, each a Lead or a Developer in it, and is given projects or whole clients. A client gives it every project of that client, including ones added later.
- A project can belong to several teams. A person can be in several teams, with a different role in each.
- Owners and admins create, rename and delete teams, give them projects and clients, and choose Leads. A Lead adds and removes Developers in their own team.
- A project no team has is seen only by owners, admins and Viewers. Owners and admins see “N projects need a team” on Now, and P1s on that project go to them.
- Project owners still change a project’s settings (code review, merge gate, kind) and get its P1s. With teams, a project owner must be on one of the project’s teams; one who leaves them stops owning the project.
- A member in no team sees nothing yet; Now tells them to ask an owner or admin.
Once an organisation has teams, they can’t be switched off while any team exists, so access never widens by accident. An admin deletes the teams first, on purpose.
What a team member sees
Section titled “What a team member sees”Only their teams’ projects, everywhere: Now, the Overview, Issues, Assets, advisory and finding pages, the public API, MCP and Ask Lilly. An advisory that touches their project and another team’s shows only their part. Another team’s advisory, finding or target is simply not there.
Of the organisation-wide pages they see the evidence log (only entries about their projects, and no evidence packs), supply chain blocks and their own proxy key, and the people in their teams (a Lead sees everyone, to add Developers). Clients, notices, invites, AI spend and the organisation’s settings are for owners and admins.
Who gets alerts
Section titled “Who gets alerts”| Without teams | With teams | |
|---|---|---|
| P1 alert (at once) | Owners and admins get every fix in it; each project owner gets the fixes that touch their projects. | Each fix goes to its projects’ owners and the Leads of the teams that have them, each with their own projects. Owners and admins get what no team answers for. |
| Escalation (a P1 nobody acknowledged in 4 hours) | Everyone in the organisation. | Every owner and admin, and everyone on the teams that have its projects. Never the whole organisation. |
| Daily (P2) and weekly (P3) digests | Owners and admins. | Owners and admins. |
More on priorities, deadlines and digests: Priorities and deadlines.
Access review
Section titled “Access review”With teams on, owners and admins see an access review on Now each calendar quarter (for example “Access review 2026-Q4”) until it is done. The review lists everyone with their role, their teams and the projects they see. Each person is either kept, or removed from all their teams. Owners, admins and Viewers see every project whatever their teams, so their access changes on Members. Every person needs a decision, and you can’t remove yourself. Viewers can read the review; owners and admins complete it.
The completed review is stored as it stood and never changes. It goes into the evidence log with the number of people, who was removed and a hash of the snapshot, and evidence packs list the period’s reviews under Access reviews, mapped to ISO 27001 A.5.18 and SOC 2 CC6.2 and CC6.3.
Evidence of who acted
Section titled “Evidence of who acted”Every evidence record a person causes carries their role at the time and, with teams, their teams. An auditor reads what someone could do when they acted, not what they can do now.