Team & Roles
From the Professional plan on, you can invite people to your account. Every member has a workspace role that decides what they can see and do in the projects they can open. How many members and maintainers your plan includes is listed in Account and Plans.
This page describes each role, how project access works, and how invitations and removals behave.
Tenant team page showing members, their roles and pending invitations.
Role Model
Mockomat has four workspace roles. Each role includes everything of the roles above it.
| Role (in the API) | Summary |
|---|---|
Readonly (readonly) | Sees projects, the model and the data preview; reads board notes |
Reporter (reporter) | Also writes board notes and their comments |
Editor (editor) | Also builds the model, creates projects, manages API keys and runs code export |
Maintainer (maintainer) | Also deletes projects, manages members, their project access and workspaces |
The owner is the person who created the account. The owner is a maintainer, is the only one who manages billing, and cannot be removed from the account.
Project Access
- Maintainers see every project of the account.
- Other members see the projects they were given access to. When you invite someone, you choose All projects of the workspace (current and future ones) or Specific projects.
- For a specific project, you can override the member's role for that project or exclude the project. An override can restrict the role for that project, but never raise it above the member's workspace role.
Readonly
For stakeholders, clients and consumers who need to look, not change.
Can:
- Open the projects they have access to: modelling board, tables, attributes, relations, operations and the runtime preview
- Read board notes and their comments
- See the project's API keys and download code packages others generated (Professional and above)
Cannot:
- Write board notes or comments
- Change the model, create or delete projects
- Manage API keys, members or billing
Reporter
For reviewers who give feedback without changing the model.
Adds to Readonly:
- Create, edit and delete board notes and comments
- Open endpoint analytics (Business and above)
Cannot:
- Change the model, create or delete projects
- Manage API keys, members or billing
Reporter adding a board note on the modelling board.
Editor
The working role for developers and modellers.
Adds to Reporter:
- Create projects and change project settings, including share and collaboration links
- Build the model: tables, attributes, relations, mappings, views and operations
- Import OpenAPI specifications
- Create and revoke API keys (Professional and above)
- Run code export (Professional and above)
- Fork projects and clone blueprints into a workspace
Cannot:
- Delete projects
- Invite or remove members, or change their project access
- Manage workspaces or billing
Editor view of the modelling board with full editing controls.
Maintainer
For the people who run the account's projects and team.
Adds to Editor:
- Delete projects
- Invite and remove members and set their project access (Professional and above)
- Create, rename and schedule the deletion of workspaces (a workspace is deleted after a 14-day grace period, during which a maintainer can cancel the deletion)
- See every project of the account
Cannot: manage billing — that stays with the owner.
Owner
The owner created the account and holds a maintainer seat.
- Everything a maintainer can do
- Change the plan, manage payment details and invoices, and cancel the subscription (see Billing and Invoices)
There is one owner per account. Ownership cannot be transferred in the app.
Capability Matrix
| Capability | Readonly | Reporter | Editor | Maintainer |
|---|---|---|---|---|
| Open assigned projects and the preview | ✓ | ✓ | ✓ | ✓ |
| Read board notes | ✓ | ✓ | ✓ | ✓ |
| Write board notes and comments | — | ✓ | ✓ | ✓ |
| Endpoint analytics (Business+) | — | ✓ | ✓ | ✓ |
| Build the model and operations | — | — | ✓ | ✓ |
| Create projects | — | — | ✓ | ✓ |
| Create and revoke API keys | — | — | ✓ | ✓ |
| Run code export | — | — | ✓ | ✓ |
| Delete projects | — | — | — | ✓ |
| Manage members and project access | — | — | — | ✓ |
| Manage workspaces | — | — | — | ✓ |
| See every project of the account | — | — | — | ✓ |
Billing is the owner's alone.
Role capability matrix.
Seats per Plan
| Plan | Team members | Maintainer seats |
|---|---|---|
| Starter | 1 (only you) | — |
| Professional | 11 | 1 |
| Business | 19 | 3 |
| Enterprise | 26 | 5 |
Team members and maintainer seats include you, the owner — on Professional, the one maintainer seat is yours. Invitations need Professional or above.
Invite Flow
- Open Account → Tenant → Tenant team and choose Invite Member (maintainers only).
- Enter the invitee's email address (one address per invitation).
- Pick the workspace role.
- Choose project access: all projects of the workspace, or specific projects with optional per-project overrides.
- Send the invitation. It is valid for 7 days.
- The invitee opens the link and signs in or creates an account; the role applies as soon as they accept.
Pending invitations appear on the team page and can be revoked before they are accepted.
Changing a role: there is no role switch for existing members. Remove the member and invite them again with the new role.
Removing a member: removing a member signs them out and ends their access to the account's projects. Board notes and comments they wrote stay on the board.
Invite flow with email entry, role selection and project access.
Sign-In Sessions
- On Starter, an account can be signed in in one place at a time: signing in elsewhere ends the earlier session.
- On Professional, Business and Enterprise, the account owner can stay signed in on several devices at once.
- Invited members do not get this from the account they join: they are signed in in one place at a time unless they own an account whose plan allows more.
- On every plan, members are signed out automatically after a period without activity.
Best Practices
Start with minimal roles. Give each member the lowest role that lets them do their work, and raise it when the need arises.
Use Reporters for review. Instead of making every reviewer an Editor, use the Reporter role and board notes for structured feedback. The model stays stable while the discussion stays visible.
Keep maintainer seats for the people who run the team. Maintainers manage members and delete projects; everyone who only models needs the Editor role.
Grant project access deliberately. For contractors and clients, invite with specific projects instead of all projects.