DocsAccount & settings

Workspace and members

Settings in two tabs. Project Settings holds the collection config, notifications, Search Console and tracking. Workspace holds members and roles, API keys, the audit log, and the Danger Zone.

This is where you run the account: who gets access and at what level, how a project collects, and how to export or delete everything. Settings splits into two tabs by scope:

  • Project Settings: everything about the selected project. How it collects (its collection config, below), Slack/webhook notifications, the Google Search Console connection, and shortcuts to prompts, competitors, and the brand hub.
  • Workspace: the account itself. Its name, your team members and their roles, API keys, the audit log of who did what, and the Danger Zone for exporting or deleting data.

The rule that saves the most headaches: most limits are pooled and enforced at the workspace level (seats, prompts, brands), and access is decided by role, checked on the server. So a "client viewer" seat really can't change anything, whatever they click.

The collection config

Every project has exactly one collection config. It sets the markets the project samples (up to five countries from the 241-country catalog, the first one being the project's primary market), an optional persona the prompts are asked as, and the engines this project collects with.

The workspace picks a default engine set on Engines, up to your plan's engine slots. The picker only offers engines your plan can hold. Every project starts by inheriting that set. On a project's Collection card, Customize gives that project its own set within the same slots. Reset clears the override and follows the workspace default again. Inheriting projects pick up later default changes automatically. Slots are billed once per workspace, so a project's own set never costs extra slots.

The config is created with the project during onboarding and edited here. There is deliberately no way to add a second config or delete the one you have. Another market goes into this config's market set, not into a second project. Every prompt is asked once per market, so each market you add spends more of your daily prompt checks.

  • Pause / resume stops and restarts collection for the project. A paused project is skipped on collection cycles until resumed.
  • Changes apply from the next collection cycle, never retroactively. History keeps the scope it was really collected under.
  • Collection health (status, last run, per-engine coverage) lives on the Overview's Collection strip, which links back to this card.

Members and roles

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. 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 and 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 we send 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 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?" It names 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.

When an invite is addressed to a specific email, only the matching account may accept it. If you're signed in as anyone else, the screen says so and the join is refused. The address is a real restriction, not just a label. An account created on or after 11 July 2026 must also have verified that email before it can accept an invite sent to it. Accounts older than that predate email verification and are exempt, so no existing customer is ever locked out of an invite addressed to them. A bare invite with no address is "whoever holds the link", so any signed-in account can claim it.

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.

Two other refusals are not dead ends. An invite addressed to a different email won't accept while you're signed in as the wrong account. An addressed invite won't accept until the matching account has verified its email. Neither one spends the invite. Sign in as the right account, or verify your address, reopen the same link, and the join completes.

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 keep a workspace from being left unmanageable. The last owner 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. You can't change an admin's or owner's project access. You can't promote a project-scoped member straight to admin or owner, so widen them to all projects first. 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
Starter2
Growth2
Advanced5
Agency Starter5
Agency Growth10
Agency Advanced10

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. There is 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 the Workspace tab, owners and admins get a Danger Zone with two self-serve controls:

  • Export your data: downloads everything the workspace owns as one zip. At the workspace level: the workspace record, its members, and pending invites (each invite carries the address it was sent to, but never its live link token), plus the full audit log. Then, for every brand, a folder holding its prompts and their topics, competitors, the collection config (as monitors.json, the data model's name), full answer texts, citations, mentions, daily metrics, your prompt-research history (seed phrases, full result sets, and spend), the prompt-suggestion queue, site-health crawls and per-URL page measurements, the page-tracker roster (citation snapshots and DataForSEO ranks), the community threads (YouTube / Reddit) engines cited for you, your uploaded knowledge sources (with their full extracted text), and any content drafts, briefs, and saved setups. Plus the brand's own identity and settings, including white-label report branding. A manifest.json states when the bundle was generated and spells out exactly what is and isn't included. The honest not-included list names raw engine payloads (left out for size; the verbatim answer text is still in the answers file), retrieved-but-not-cited URL lists, server logs and Stripe invoices, re-derivable caches, and the operational surfaces the app re-computes from data already in the bundle: alerts, the action-item board, answer-gap rows, prompt briefs, per-day GSC / visitor / crawler analytics aggregates, shopping placements, and report-schedule run logs. The manifest carries the full list, and support can get you any of these raw. Nothing is silently missing. 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 the Project Settings tab, Danger Zone. That is this page's #danger anchor, a project-level Danger Zone separate from the workspace one above. Archive stops collection and frees the brand's plan slots. Every answer and metric is kept, labeled as archived and 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.