Team & Roles

Every team member invited to a workspace is assigned a role that governs their permissions across the entire workspace. Roles define what each person can see, comment on, edit, and administer. The set of available roles and the number of seats per role depend on the active plan.

This page describes each role in detail, explains their capabilities and constraints, and provides reference tables for quick comparison across plans.

tr-01-team-overviewMissing

Team members panel showing assigned roles and invitation status.

---

Role Model

Mockomat uses a four-tier role model. Each tier inherits all permissions from the tier below it, with one exception noted under the Enterprise Maintainer section.

Role	Summary
Extern	Read-only third-party access
Reporter	Read access plus team communication
Maintainer	Near-full editing capabilities
Owner	Full workspace control

Roles are assigned at the workspace level. There is no per-project role assignment — a member's role applies uniformly to all projects within the workspace.

---

Extern

An Extern is a read-only third-party user, typically a client, stakeholder, or external API consumer who needs visibility into the project without the ability to make changes.

Permissions:

• View all projects in the workspace
• View the modelling board, entities, attributes, and relations
• View configured GraphQL operations and their parameters
• Access public-facing runtime endpoint documentation
• View data source mappings and configuration summaries

Restrictions:

• Cannot add comments or address messages to other users
• Cannot edit any modelling configuration
• Cannot create, rename, or delete projects
• Cannot access the import wizard or data management areas
• Cannot manage users, roles, or billing

Typical use: Sharing project progress with a client who needs to verify the API shape before integration work begins, or giving an external developer read access to understand the data model without risk of accidental modification.

---

Reporter

A Reporter has all Extern permissions plus the ability to participate in team communication through the comment system. This role is designed for team members who review and provide feedback but do not make model changes directly.

Additional permissions (beyond Extern):

• Add comments on projects and project-level discussions
• Add comments on modelling entities, attributes, and relations on the modelling board
• Address comments to specific team members using @mentions
• Resolve their own comments
• View the full comment history and activity log

Restrictions:

• Cannot edit any modelling configuration
• Cannot create, rename, or delete projects
• Cannot access the import wizard or data management areas
• Cannot manage users, roles, or billing

Typical use: A product manager who reviews domain models and leaves feedback for the development team, or a QA engineer who flags inconsistencies in the modelling board without modifying the model directly.

tr-02-reporter-commentMissing

Reporter adding a comment on a modelling entity with @mention.

---

Maintainer

A Maintainer is a trusted team member with near-full editing capabilities. This is the primary working role for developers and modellers who actively build and configure projects.

The exact scope of Maintainer permissions depends on the active plan.

On Professional and Business Plans

Additional permissions (beyond Reporter):

• Create, edit, and delete projects
• Configure modelling: add, edit, and delete entities, attributes, relations, and views
• Configure GraphQL operations via the API design panel
• Manage API keys (create, revoke, rotate)
• Run the import wizard for datasets
• Access the full mock runtime and preview area
• Export code artifacts

Restrictions on Professional and Business:

• Cannot invite, remove, or change the roles of other users
• Cannot change billing or subscription settings
• Cannot delete the workspace

On Enterprise Plan

Enterprise Maintainers retain all editing capabilities described above with one additional restriction: they cannot access the tenant-scoped mock data import pipeline or the global mock data management area. These capabilities are reserved exclusively for the Owner to protect proprietary dataset integrity.

Additional restrictions on Enterprise:

• Cannot import or manage tenant-scoped proprietary datasets
• Cannot access the mock data administration area
• Cannot manage users or billing

For full details on Enterprise data governance, see the Enterprise documentation.

tr-03-maintainer-workspaceMissing

Maintainer view of the workspace with full editing controls visible.

---

Owner

The Owner is the workspace account holder with unrestricted control over every aspect of the workspace. Every workspace has exactly one Owner.

Permissions:

• All Maintainer capabilities without restriction
• Invite, remove, and reassign roles for all team members
• Change the subscription plan and manage billing details
• On Enterprise: manage proprietary dataset imports and the mock data administration area
• Delete the workspace permanently

Ownership transfer: Ownership can be transferred to another team member from Account → Team → Transfer Ownership. The transfer requires confirmation from both the current Owner and the receiving member.

---

Capability Matrix

The following matrix provides a complete reference of what each role can do across all workspace areas.

Capability	Extern	Reporter	Maintainer	Owner
View projects	✓	✓	✓	✓
View modelling board	✓	✓	✓	✓
View data source mappings	✓	✓	✓	✓
View runtime docs	✓	✓	✓	✓
Add comments	—	✓	✓	✓
@mention team members	—	✓	✓	✓
Resolve own comments	—	✓	✓	✓
Edit modelling configuration	—	—	✓	✓
Create / delete projects	—	—	✓	✓
Configure API operations	—	—	✓	✓
Manage API keys	—	—	✓	✓
Run import wizard	—	—	✓	✓
Export code	—	—	✓	✓
Access runtime preview	—	—	✓	✓
Manage team members	—	—	—	✓
Manage billing	—	—	—	✓
Tenant data import (Enterprise)	—	—	—	✓
Delete workspace	—	—	—	✓

tr-04-capability-matrixMissing

Role capability matrix as displayed in the account settings.

---

Role Availability per Plan

Not all roles are available on every plan. The table below shows how many seats of each role are included with each plan tier.

Role	Guest	Free	Professional	Business	Enterprise	Custom
Owner	✓	✓	✓	✓	✓	✓
Maintainer	—	—	1	3	5	Configurable
Reporter	—	✓ (max 1)	✓	✓	✓	✓
Extern	—	✓ (max 1)	✓	✓	✓	✓

On the Free plan, the single additional user slot can be assigned as either an Extern or a Reporter — not both. From Professional onward, there are no restrictions on the mix of Reporter and Extern seats within the total user limit.

For a full comparison of plan features beyond roles, see the Account and Plans documentation.

---

Invite Flow

Adding a team member to your workspace follows a straightforward process.

1. The Owner navigates to Account → Team.
2. Enter the invitee's email address and select the desired role from the dropdown.
3. An invitation email is sent to the provided address.
4. The invitee clicks the invitation link and either signs in or creates a new Mockomat account.
5. Upon acceptance, the assigned role takes effect immediately.

Pending invitations are visible in the Team panel with a status indicator. The Owner can revoke a pending invitation at any time before it is accepted.

Role changes after acceptance: The Owner can change any member's role from the Team panel. Role changes take effect on the member's next page load — no re-invitation is required.

Removing members: Removing a member revokes their access immediately. Any comments they authored remain visible but are attributed to a deactivated account label.

tr-05-invite-flowMissing

Invite flow with email entry, role selection, and pending status.

---

Session Management

Every plan controls how many simultaneous authenticated browser sessions are permitted across the workspace.

Plan	Concurrent Sessions	Idle Timeout
Guest	1	15 minutes
Free	2	15 minutes
Professional	5	15 minutes
Business	15	15 minutes
Enterprise	50+ (configurable)	Configurable
Custom	Configurable	Configurable

Session behaviour:

• Each authenticated browser tab counts as one session.
• Sessions expire after the idle timeout period with no user activity.
• When the session limit is reached, the oldest idle session is released to accommodate the new login.
• If all sessions are active (no idle sessions available), a new login attempt is blocked until a session becomes available.

Enterprise and Custom plans can configure both the session limit and the idle timeout duration through the tenant administration panel. For details, see Enterprise.

---

Best Practices

Start with minimal roles. Assign the most restrictive role that still allows each team member to do their work. Promote to a higher role when the need arises — it is easier to grant additional permissions than to audit overexposure after the fact.

Use Reporters for review workflows. Rather than granting Maintainer access to everyone who needs to provide feedback, assign the Reporter role and use the comment system for structured review. This keeps the modelling board stable while enabling team communication.

Reserve Maintainer seats for active modellers. On plans with a limited number of Maintainer slots, assign these to team members who actively build and configure the domain model. Stakeholders and reviewers should use the Reporter or Extern role.

Document role assignments. For teams with more than a few members, maintain a brief record of who holds which role and why. This is especially important on Enterprise plans where Maintainer restrictions around data import differ from other tiers.

---

Free plan guidance

Free User

On the Free plan, you have one additional user slot. Use it to invite a stakeholder as a Reporter so they can leave feedback directly on the modelling board — or as an Extern if they only need to observe. You can change the role at any time from the Team panel without re-inviting.

Professional plan guidance

Registered User

With one Maintainer slot on the Professional plan, designate your most active modeller as the Maintainer and use Reporter roles for everyone else who needs to participate. Use @mentions in comments to keep design decisions traceable and addressable within the workspace context.

Business plan guidance

Paid User

The Business plan provides three Maintainer slots. Distribute these across domain areas so that each active modelling area has a responsible Maintainer. Use the capability matrix above to set clear expectations for each team member's scope of action.

Enterprise guidance

Enterprise User

On the Enterprise plan, be aware that Maintainers cannot access tenant-scoped data imports or mock data administration. Plan your team structure so that the Owner or a designated delegate handles proprietary dataset management. For organizations with complex team structures, consider the [Custom plan](/en/account/) for configurable role limits.