DocsAccount & settings

Workspace and members

The workspace hub for team members and roles, regions, notifications, API keys, Google Search Console, and an audit log of access-relevant changes.

Settings is the workspace hub. From here you manage the people in your workspace and what they can do, along with regions, notifications, API keys, Google Search Console, and the audit log.

What it does

A workspace groups everything under one team and one plan: its brands, prompts, members, and billing. The members area controls who has access and at what level, and every access-relevant change is written to an audit log so you can see who did what.

There are four roles:

RoleCan do
OwnerEverything, including billing and granting or revoking ownership.
AdminManage members, API keys, and billing; cannot touch the owner role.
MemberFull read and write on the workspace's data.
Client viewerRead-only. Shares dashboards without any edit rights.

Client-viewer seats are how an agency hands a client a live view of their reports without giving anyone edit access.

How to use it

You add people by creating an invite, choosing the role it will grant. Every invite is a single-use link that expires after seven days, so a link that leaks or sits in an inbox stops working on its own.

  • Invite a member — create an invite for admin, member, or client viewer. An invite can never grant the owner role.
  • Email the invite (optional) — address the invite to an email and MentionFlow sends the link for you. Delivery is honest: a "sent" confirmation only appears after the email provider accepts the message. If email isn't configured on the install, the invite is still created — you just copy the link and share it yourself. You can resend or revoke a pending invite from the members list.
  • Restrict access to specific projects — in agency setups you can scope an invite, or an existing member, to chosen brands; only brands in your own workspace are accepted. This applies to members and client viewers only — owners and admins always have workspace-wide access (see below).
  • Change a role — promote or demote an existing member. Only an owner can grant or revoke ownership.
  • Remove a member — revoke access at any time.
  • Transfer ownership — promote another member to owner before you step down.

What happens when someone accepts

Opening a valid invite link while signed in shows a confirmation screen — "Join workspace as role?" — naming the workspace, the role the invite grants, and the account you're signed in as. Nothing happens until you confirm: joining takes an explicit click on the join button, so merely opening a link never enrolls anyone. If the invite was addressed to a different email than the account you're signed in as, the screen says so and notes that joining links your signed-in account to the workspace — the address records who the invite was meant for, it doesn't restrict who can use the link.

A signed-out visitor is asked to sign in or create an account first, then sees the confirmation screen on reopening the link. Because the link is single-use, the first person to confirm it claims it; a dead link then says honestly why it's dead — already claimed by someone else, already used by you (with a button to your dashboard), expired, or revoked. If the workspace has hit its seat cap by the time someone confirms, the join is refused rather than silently over-filling the plan — the link stays valid and works once a seat frees up. Every acceptance is written to the audit log.

Note

A read-only client viewer who reaches an edit action is stopped everywhere, not just in the UI. Write access is derived from role on the server, so hiding a button is never the only thing standing between a viewer and a change. The same fence means an operator in support view (view-as) can never manage members — they hold no membership in the workspace they're viewing, so member, invite, role, and scope controls are all read-only for them.

How it's computed / enforced

Only owners and admins can manage members; only an owner can create, grant, or revoke the owner role. Two guards protect the workspace from being left unmanageable: the last owner of a workspace cannot be removed, and the last owner cannot be demoted out of the owner role. Ownership must be transferred first.

Project scoping is a member and client-viewer boundary only. Admins and owners always have workspace-wide access, so MentionFlow refuses to create a "scoped admin": you can't scope an admin invite, can't change an admin's or owner's project access, and can't promote a project-scoped member straight to admin or owner (widen them to all projects first). This keeps the boundary real — the access gates run on role, so a scoped admin could simply un-scope themselves.

Team-seat caps are enforced per plan at two points: when an invite is created, and again when it is accepted. Creating an invite past the seat count is refused with an upgrade prompt; the acceptance re-check catches the case where several invites were minted just under the cap and then all accepted — the one that would exceed the cap is turned away and its link stays usable until a seat frees. Seats count actual members, so a revoked or removed member frees one immediately.

PlanSeats
Trial3
Starter5
Growth15
Agency50
Scale1,000

The audit log records access-relevant events: member role changes, project-scope changes, and removals; invites created, emailed, accepted, and revoked; API keys created and revoked; scheduled-report changes; password-reset requests and completions and email verifications; billing checkout and portal and plan changes; Google Search Console connect / property-selection / disconnect; support-view sessions; Cloudflare Worker connect and disconnect; data exports; brand archive / restore / delete; and workspace deletion. The log is deliberately fire-safe — a failure to record an event never blocks the change it was recording — with one deliberate exception: an invite acceptance that grants a membership is recorded atomically with the grant, so a new member can never join unaudited.

Danger Zone: export and delete

At the bottom of Settings, owners and admins get a Danger Zone with two self-serve controls:

  • Export your data — downloads everything the workspace owns as one zip: full answer texts, mentions, citations, daily metrics, prompts, competitors, monitors, members, invites (including the address an invite was sent to — never its live link token), the audit log, and per-brand settings, with a manifest stating the generation date and exactly what is and isn't included (raw engine payloads stay out, and the manifest says so). Every export is audit-logged.
  • Delete this workspace — owner-only, and you must type the workspace's name to confirm. An active subscription is cancelled with Stripe first — if that cancellation can't be confirmed, nothing is deleted. The deletion then erases every project, answer, metric, member, API key, and the audit trail itself in one atomic cascade. It cannot be undone; download the export first.

Brands have their own archive and delete controls in Brand hub → Danger Zone: archive stops collection and frees the brand's plan slots while keeping every answer and metric (labeled as archived, excluded from portfolio blends by default); delete permanently erases the brand's data with the same typed-confirmation pattern.

Limits

  • Seats are capped per plan (see the table above and Plans and quotas), and are re-checked on both invite creation and acceptance.
  • Invites are single-use and expire after seven days.
  • Only owners and admins can create or manage invites; an invite can never grant the owner role, and only an owner can grant ownership.
  • Project scoping applies to members and client viewers only, never owners or admins.
  • Emailed invites require outbound email to be configured on the install; otherwise, copy and share the link manually.
  • A workspace must always have at least one owner.