DOCS

Roles & permissions

Four roles, what each one can see, and why a rep gets a 404 rather than a 403.

RepCue has four roles in a strict hierarchy: service → admin → manager → rep. A permission granted to a lower role is always available to a higher one.

What each role does

RepManagerAdmin
HomeMy day: upcoming calls and briefs, unshipped post-call items, own stats, drillsTeam cockpit: live floor, coaching queue, at-risk deals, adoptionOrg health: seats, pool burn, integrations, knowledge freshness, consent coverage
CallsTheir ownTheir teams'The org's
DealsDeals they own or ran a call onTheir teams'The org's
AnalyticsTheir own numbersTheir teams', per-rep breakdown, leaderboardThe org
CoachingDrills assigned to them, their scorecardsReview and override scorecards, comment, clip, assign drillsSame as manager, org-wide
Live floorListen in, private whisper coachingSame
KnowledgeReadAuthor playbooks and battlecardsSame, plus connectors
TeamsSee teams they manageCreate, edit, assign managers and members
SettingsTheir own profile and notificationsTeam goals, scorecard reviewEverything: integrations, SSO/SCIM, policies, API keys, webhooks, billing, audit, retention

Service is not a human role. It is the identity live-plane services use to talk to the control plane, and it outranks admin on a short allow-list of endpoints. See Public API & webhooks.

Read scoping: the rule every list obeys

Row-level security keeps organisations apart. Scoping keeps people apart inside one organisation.

Every scoped endpoint accepts ?scope=me | org | team:<id>, and the server, not the client, decides what that resolves to:

RoleDefault scopeMay requestNotes
repmeIgnored; always forced to meA rep who opens a manager's URL sees their own data, not an error they can't act on
managerTheir teams + themselvesme, or a team:<id> they manageorg is refused with 403 while they manage any team
manager with no teamorgme, orgA documented fallback so an org that hasn't modelled teams isn't left with an empty console
admin / serviceorgAnything

An empty team allow-list matches nothing, never everything. A manager whose team has no members sees no rows: the failure mode is an empty screen, not the whole org.

Scoping applies to: calls (including transcript search), deals and forecast, every analytics module (including the leaderboard and CSV exports), coaching, usage events, and global search.

Why single items return 404, not 403

Fetching one call, deal, transcript, artifact, comment, snippet, scorecard or recording that is out of scope returns 404, not 403.

A 403 would confirm the thing exists. Someone iterating over identifiers could learn which calls a colleague ran; the existence of the record is itself information. Returning 404 means an out-of-scope record is indistinguishable from one that was never there.

"View as": read-only impersonation

An admin can look at the product exactly as another user sees it. It is the answer to "the dashboard looks wrong on my screen".

Three constraints make it safe to hand to a support team:

  1. The token lasts 15 minutes.
  2. It is strictly read-only. Any non-GET request under a view-as session is refused with 403, enforced centrally at authentication, so no individual route has to remember the rule.
  3. Every request is audited with both identities: the admin who started it and the user being viewed. There is no way to act as someone else without a record naming you.

While a view-as session is active the console shows a persistent banner and suppresses every mutating control.

Changing roles

Admins change roles at Settings → People. Two guard rails apply:

  • The last admin cannot be demoted or deleted, so an org can never lock itself out.
  • Promoting or inviting is seat-checked against the subscription.

Deactivating a user revokes their sessions immediately.

Roles can also be driven from your identity provider; see SSO & SCIM.