Comments are the primary mechanism for team communication within the Mockomat workspace. They allow team members to discuss design decisions, raise questions, and coordinate modelling work directly on the elements they concern — without leaving the workspace or switching to an external tool.
Every comment is contextual. Rather than existing in a detached conversation thread, each comment is anchored to the specific project, entity, attribute, or relation it addresses. This ensures that discussions remain traceable and that decisions are visible to anyone reviewing the model later.
Comments are available from the Free plan onward. See Account and Plans for full plan details.
collab-comments-01-overviewMissing
Comment thread on a project overview page with multiple participants.
Comments surface in two distinct contexts within the workspace. Both contexts share the same interaction model — creating, replying, mentioning, and resolving — but differ in what they are attached to.
A project-level comment thread is attached to the project overview. It is visible to all workspace members who have access to that project. Use project-level comments for broad discussions: naming conventions, scope decisions, timeline coordination, or any topic that applies to the project as a whole rather than a specific modelling element.
Project-level comments appear in chronological order. Each comment displays the author, timestamp, and any @mentions. Resolved comments collapse but remain accessible through a filter toggle.
collab-comments-02-project-levelMissing
Project-level comment thread with resolved and open comments.
On the modelling board, comments can be anchored to specific elements:
Entities — discuss the purpose, naming, or scope of a table.
Attributes — raise questions about data types, mapping choices, or field naming.
Relations — debate cardinality decisions, direction semantics, or linking column correctness.
Board-level comments appear as indicators on the element they are attached to. Clicking the indicator opens the comment thread in a side panel without navigating away from the board. This keeps the spatial context intact while you read and respond.
collab-comments-03-board-anchoredMissing
Comment indicator on a relation line, with the thread open in the side panel.
Comment permissions follow the workspace role model. The table below summarises what each role can do with comments:
Role
Read
Create
Reply
Resolve
Extern
Yes
—
—
—
Reporter
Yes
Yes
Yes
Own only
Maintainer
Yes
Yes
Yes
Any
Owner
Yes
Yes
Yes
Any
Extern users have read-only access. They can see all comments on projects and board elements they can view, but they cannot create, reply to, or resolve any comment.
Reporter users can create new comments and reply to existing threads. They can resolve comments they authored, but not comments created by others.
Maintainer and Owner roles have full comment capabilities, including the ability to resolve any comment regardless of authorship.
Every comment supports threaded replies. When a team member responds to an existing comment, the reply is nested under the original message, forming a focused conversation. Threads keep discussions organised — a single entity may have multiple independent comment threads addressing different concerns.
Type @ followed by a team member's name to mention them directly. Mentioned users receive a notification (in-app and, where configured, via email) alerting them to the comment. Use @mentions to draw specific attention:
Mention a frontend developer when an attribute name changes that affects their query structure.
Mention the Owner when a cardinality decision requires sign-off.
Mention a Reporter to request review feedback on a new entity.
collab-comments-04-mentionMissing
@mention autocomplete dropdown while composing a comment on an entity.
When a comment has been addressed — the question answered, the decision made, the change applied — any authorised user can mark it as resolved. Resolved comments collapse in the thread view but are never deleted. They remain part of the project's audit trail and can be reopened if the topic resurfaces.
Resolving is a lightweight workflow signal. It communicates to the team that this item no longer requires attention, without erasing the reasoning that led to the resolution.
All comment activity — creation, replies, mentions, and resolutions — is recorded in the project activity log. The activity log provides a chronological record of every significant event in the project, and comments are interleaved with modelling changes, import events, and configuration updates.
This integration means you can review the full history of a modelling decision: the structural change on the board, the comment thread discussing it, and the resolution that closed the discussion — all in a single timeline.
collab-comments-05-activity-logMissing
Project activity log showing comment events interleaved with modelling changes.
Comments are persisted permanently. Even when a comment is resolved or the authoring user is later removed from the workspace, the comment text, author attribution, and timestamp remain intact. Removed users are displayed as deactivated accounts, preserving the historical record without exposing active contact information.
Comments are most valuable when used deliberately. The following patterns reflect proven approaches to keeping modelling discussions productive and traceable.
Pin Comments on Relations for Cardinality Discussions
When a relation's cardinality is uncertain — is this truly 1:n, or should it be m:n? — anchor a comment directly on the relation line. This ensures the discussion is visible to anyone inspecting the relation and prevents the same question from being raised repeatedly.
When a naming change on the modelling board affects downstream consumers, @mention the relevant team member. This creates an explicit notification rather than relying on passive discovery. Pair the mention with a clear description of what changed and what action is expected.
Treat Comments as Lightweight Review Checkpoints
Before finalising a section of the model, ask a team member to review by creating a comment on the relevant entity or relation. The reply thread serves as an inline review — no separate review tool is required. Resolve the comment once the review is complete.
Filter the board or project by unresolved comments to see all open decisions at a glance. This provides a task-list view of outstanding discussions without introducing a separate tracking system. Make it a team habit to resolve comments promptly once addressed.
Each comment thread should address a single concern. If a reply introduces a new topic, create a separate comment on the appropriate element rather than extending an unrelated thread. Focused threads are easier to resolve and easier to reference later.
collab-comments-06-workflowMissing
Filtered view showing only unresolved comments across the modelling board.
Comments can be edited by their author within a short window after creation. After that window closes, the comment is locked to preserve the integrity of the discussion thread. If a correction is needed, add a follow-up reply clarifying the original statement.
What happens to comments when an element is deleted?
When a table, attribute, or relation is removed from the model, any comments anchored to that element are preserved in the project activity log. They lose their spatial anchor on the board but remain searchable and readable in the chronological project history.
No. Comments are scoped to the project they belong to. A comment on Project A is not visible from Project B, even within the same workspace. This ensures that project-specific discussions do not leak across unrelated models.
Comments & Notes
Comments are the primary mechanism for team communication within the Mockomat workspace. They allow team members to discuss design decisions, raise questions, and coordinate modelling work directly on the elements they concern — without leaving the workspace or switching to an external tool.
Every comment is contextual. Rather than existing in a detached conversation thread, each comment is anchored to the specific project, entity, attribute, or relation it addresses. This ensures that discussions remain traceable and that decisions are visible to anyone reviewing the model later.
Comments are available from the Free plan onward. See Account and Plans for full plan details.
Comment thread on a project overview page with multiple participants.
Where Comments Appear
Comments surface in two distinct contexts within the workspace. Both contexts share the same interaction model — creating, replying, mentioning, and resolving — but differ in what they are attached to.
Project-Level Comments
A project-level comment thread is attached to the project overview. It is visible to all workspace members who have access to that project. Use project-level comments for broad discussions: naming conventions, scope decisions, timeline coordination, or any topic that applies to the project as a whole rather than a specific modelling element.
Project-level comments appear in chronological order. Each comment displays the author, timestamp, and any @mentions. Resolved comments collapse but remain accessible through a filter toggle.
Project-level comment thread with resolved and open comments.
Modelling Board Comments
On the modelling board, comments can be anchored to specific elements:
Board-level comments appear as indicators on the element they are attached to. Clicking the indicator opens the comment thread in a side panel without navigating away from the board. This keeps the spatial context intact while you read and respond.
Comment indicator on a relation line, with the thread open in the side panel.
Who Can Comment
Comment permissions follow the workspace role model. The table below summarises what each role can do with comments:
Comment Features
Threaded Replies
Every comment supports threaded replies. When a team member responds to an existing comment, the reply is nested under the original message, forming a focused conversation. Threads keep discussions organised — a single entity may have multiple independent comment threads addressing different concerns.
@Mentions
Type
@followed by a team member's name to mention them directly. Mentioned users receive a notification (in-app and, where configured, via email) alerting them to the comment. Use @mentions to draw specific attention:@mention autocomplete dropdown while composing a comment on an entity.
Resolving Comments
When a comment has been addressed — the question answered, the decision made, the change applied — any authorised user can mark it as resolved. Resolved comments collapse in the thread view but are never deleted. They remain part of the project's audit trail and can be reopened if the topic resurfaces.
Resolving is a lightweight workflow signal. It communicates to the team that this item no longer requires attention, without erasing the reasoning that led to the resolution.
Activity Log Integration
All comment activity — creation, replies, mentions, and resolutions — is recorded in the project activity log. The activity log provides a chronological record of every significant event in the project, and comments are interleaved with modelling changes, import events, and configuration updates.
This integration means you can review the full history of a modelling decision: the structural change on the board, the comment thread discussing it, and the resolution that closed the discussion — all in a single timeline.
Project activity log showing comment events interleaved with modelling changes.
Audit Trail
Comments are persisted permanently. Even when a comment is resolved or the authoring user is later removed from the workspace, the comment text, author attribution, and timestamp remain intact. Removed users are displayed as deactivated accounts, preserving the historical record without exposing active contact information.
Effective Workflows
Comments are most valuable when used deliberately. The following patterns reflect proven approaches to keeping modelling discussions productive and traceable.
Pin Comments on Relations for Cardinality Discussions
When a relation's cardinality is uncertain — is this truly 1:n, or should it be m:n? — anchor a comment directly on the relation line. This ensures the discussion is visible to anyone inspecting the relation and prevents the same question from being raised repeatedly.
Use @Mentions for Cross-Role Coordination
When a naming change on the modelling board affects downstream consumers, @mention the relevant team member. This creates an explicit notification rather than relying on passive discovery. Pair the mention with a clear description of what changed and what action is expected.
Treat Comments as Lightweight Review Checkpoints
Before finalising a section of the model, ask a team member to review by creating a comment on the relevant entity or relation. The reply thread serves as an inline review — no separate review tool is required. Resolve the comment once the review is complete.
Resolve to Track Progress
Filter the board or project by unresolved comments to see all open decisions at a glance. This provides a task-list view of outstanding discussions without introducing a separate tracking system. Make it a team habit to resolve comments promptly once addressed.
Keep Comments Focused
Each comment thread should address a single concern. If a reply introduces a new topic, create a separate comment on the appropriate element rather than extending an unrelated thread. Focused threads are easier to resolve and easier to reference later.
Filtered view showing only unresolved comments across the modelling board.
Availability per Plan
Comment functionality scales with your plan. The table below summarises feature availability:
Common Questions
Can I edit a comment after posting?
Comments can be edited by their author within a short window after creation. After that window closes, the comment is locked to preserve the integrity of the discussion thread. If a correction is needed, add a follow-up reply clarifying the original statement.
What happens to comments when an element is deleted?
When a table, attribute, or relation is removed from the model, any comments anchored to that element are preserved in the project activity log. They lose their spatial anchor on the board but remain searchable and readable in the chronological project history.
Are comments visible across projects?
No. Comments are scoped to the project they belong to. A comment on Project A is not visible from Project B, even within the same workspace. This ensures that project-specific discussions do not leak across unrelated models.
Related Pages