A mention links a message to a specific person or group. In a collaborative SaaS product, typing a name is not enough: the interface must help the author select the right identity, explain who can see the message, and connect the recipient to the relevant context. A useful mention brings a person into the conversation without making them reconstruct the task.

Mentions are often represented by an @ token, but their behavior matters more than their visual form. A mention may notify someone, make a reference navigable, or help direct attention. It should not silently assign responsibility or grant access unless those are explicit parts of the workflow.

Use a mention to direct attention, not to replace a task

A mention is appropriate when a colleague’s input helps resolve a question. It can ask for review, clarify a decision, or connect someone with expertise. The surrounding message should explain what is needed so the recipient can act when they arrive.

If work must have an owner and due date, use a task or assignment mechanism. A message saying “@Alex please check” may attract attention without establishing accountable work. The product should distinguish a notification from an assignment and avoid counting mentions as completed delegation.

Similarly, a mention is not automatically an invitation to the workspace. If the person lacks access, the composer needs to explain the consequence or offer an explicit authorized invitation path. Do not let the familiar @ syntax hide an unexpected permission change.

Front keeps the mention beside the answer being reviewed

The Front capture shows a suggested support reply inside a customer conversation. Below the draft, Marcello Smith mentions Annie and asks whether the referenced product is still featured on the company site. Annie Davis replies that it is and that the response is good to send.

The question is specific and remains beside the draft it concerns. This reduces the context the recipient must reconstruct. The recipient can see the proposed instruction and the source disclosure in the same conversation rather than receiving an isolated request in another channel.

The composer says “Add internal comment,” with helper text explaining that the comment will be visible to teammates in Support Tier 1. That visible audience distinction matters: the mention is part of an internal review, not a customer-facing reply.

The screenshot demonstrates the selected token and collaborative exchange. It does not prove how suggestions are ranked, which notification channel is used, or how access is checked. Those implementation behaviors need to be reviewed separately.

Resolve a name to an identity before submitting

An @ suggestion menu should help people distinguish possible recipients. Names alone can be ambiguous in a large organization. Use an avatar and a useful secondary identifier, such as a team or role, when duplicates exist. Do not expose extra personal information merely to make the list denser.

Search should tolerate partial names and common naming differences. The menu should make the selected candidate obvious and avoid automatically choosing the first result when several people fit. A wrong mention can disclose context to an unintended person or simply delay the work.

Show the selected identity as a stable token. If display names change, the mention should still point to the intended account. Pasted plain text that resembles “@Annie” should not become a real mention unless the product has a reliable resolution step.

If a person is unavailable, deactivated, or outside the allowed audience, distinguish that state from an ordinary result. A disabled candidate can explain why selection is unavailable; an empty list should tell the author whether no match was found or the search failed.

Explain the audience where the author composes

Who is mentioned and who can read the message are separate questions. A private thread may notify one person while remaining visible to several teammates. A public comment may mention a colleague but be readable by everyone in the project.

Place the audience label close to the composer and submission action. Front’s captured “internal comment” wording gives the author useful context at the moment of writing. If switching between an internal note and an external reply is possible, make that mode change conspicuous.

Do not rely on avatar colors or a subtle border to signal visibility. Clear text is especially important when a user is moving quickly between customer replies and colleague discussions. The content can be correct while being sent to the wrong audience.

For guest users, explain which people and groups can be mentioned. A suggestion menu should reflect the actual workspace scope rather than expose every organization member and let submission fail later.

Handle mentions of people who cannot open the item

A mention notification is frustrating if its destination immediately denies access. Check whether the selected recipient can read the relevant item. If the product supports requesting or granting access, present that as a separate, explicit action with the required permissions.

When the author cannot grant access, explain the limitation before sending. Depending on the workflow, the mention can remain a visible reference without notification, or submission may require a different recipient. The interface should state the behavior rather than leave it implicit.

Do not expose a private title or excerpt in a notification to someone who lacks access. Notification content and deep links need the same audience discipline as the original message. A mention should never be treated as permission to disclose everything around it.

Access can change after a message is posted. A historical mention may remain readable in the thread even when its account is inactive. Preserve the discussion’s meaning while making the unavailable state clear and avoiding broken identity links.

Make notifications point to the exact context

A useful notification answers who mentioned the recipient, where it happened, and what input is requested. Include a short excerpt when appropriate, and take the user to the relevant message or thread rather than the project homepage.

If the conversation is long, preserve an anchor to the mentioned comment. Highlighting the destination briefly can help orientation, provided the message remains identifiable without animation. Show the parent item and enough surrounding discussion to make the request intelligible.

Do not assume a delivered notification means the person has read or accepted the request. If the product exposes delivery or read states, label them accurately. An author may otherwise confuse “mentioned” with “reviewed.”

Let recipients control notification channels according to the product’s available settings. Email, in-app alerts, and push notifications can all serve different contexts. A mention should remain reachable in the product even when an external channel is muted.

Group mentions need scope and restraint

Mentioning a group can be useful for a shared responsibility, but the author needs to know who is included. “@Support” might refer to a team, an inbox, or an organization-wide channel. Give the candidate a clear type and relevant scope before selection.

Broad mentions such as “everyone” have a larger interruption cost. Where they are available, make their reach visible and use product permissions or confirmation appropriate to the actual audience. Do not silently expand a small-team token into every account in the company.

A group’s membership may change over time. Decide whether the mention refers to the group as a durable identity or records the recipients at the time it was posted. The user interface and notification history should not imply one model while the system implements another.

Provide a reason to choose a broad group instead of an individual. If every message mentions everyone, the signal becomes less useful. Thoughtful defaults and clear candidate labels can encourage narrower, more relevant requests without blocking legitimate teamwork.

Support editing, copying, and removal predictably

Authors should understand what happens when they edit a comment containing a mention. Adding a new recipient may notify that person; removing a token may not retract a notification already delivered. Explain consequential behavior where it matters.

A token should be editable without corrupting surrounding text. Backspace, cursor navigation, selection, and copy-and-paste need predictable results. If copied content becomes plain text in another tool, it should remain readable without falsely implying an active mention.

When a user deletes a comment, notifications should not lead to an unexplained blank destination. Show an appropriate unavailable-message state without revealing content that should no longer be accessible. Preserve enough context for the recipient to understand why the link no longer opens.

A saved draft should keep selected identities intact. If a recipient becomes unavailable before submission, check again and provide a clear resolution. The composer should not silently replace them with a similarly named account.

Make selection work with keyboard and assistive technology

The suggestion menu must be usable without a pointer. Keyboard users need to navigate candidates, select one, dismiss the menu, and continue writing. Keep focus in a predictable place and ensure that dismissing suggestions does not erase the draft.

Expose each candidate’s useful identity information to assistive technology and announce selection clearly. The selected token should be distinguishable from ordinary text without relying on color. If it can be removed, make that operation accessible.

On touch devices, provide enough space to select the intended person. A dense menu with near-identical names makes accidental selection more likely. Check the composer when the keyboard is open so suggestions and the submit action remain reachable.

Evaluate whether the mention resolved the question

Test the full path from writing to notification to contextual reply. Include duplicate names, no results, missing access, an edited mention, an inactive user, and a long thread. Each case reveals a different failure mode that a polished token alone cannot address.

For a review workflow like Front’s example, ask whether the author can make a specific request and whether the recipient can find the proposed answer immediately. The useful outcome is a resolved review question, not simply a higher volume of @ tokens.

• Resolve the recipient’s identity before submission.
• Distinguish attention from assignment and access.
• Show the message audience beside the composer.
• Deep-link notifications to the relevant comment.
• Explain group scope and unavailable recipients.
• Handle editing, deletion, and drafts predictably.
• Test keyboard, touch, and permission boundaries.

Mentions FAQ

Does mentioning someone assign them the work?

Not unless the product explicitly combines those actions. A mention directs attention; a task assignment establishes responsibility. Keep the distinction visible.

Should mentioning a person automatically grant access?

Access changes should be explicit and authorized. Check the recipient’s ability to open the item, then explain or offer the appropriate access workflow.

What makes a mention useful?

A specific request, a correctly resolved recipient, a clear audience, and a link to the exact context. The recipient should know what input is needed without searching through the workspace.

Compare SaaSFrame’s mention examples with comments and threads, notification centers, and roles and permissions to study the complete collaboration journey.