Team
Workspaces and Teams in GQ CRM: Roles, Permissions, and Multi-Client Setup
Workspaces isolate resources per team or client, and roles control who can view, edit, or delete. Here's the permission model, how to invite members, and the agency setup pattern.
Published August 19, 2026
When more than one person — or more than one client — uses GQ CRM, you need isolation and permissions. That's what workspaces and team roles are for. This guide explains the model, the four roles, and the setup pattern agencies use for multi-client sending.
1. The workspace model
Every account has a personal workspace. When you create a team, a team workspace is created with it. All resources — projects, templates, tasks, contacts, and tags — belong to a workspace, and everything you see in the UI is scoped to your active workspace (switch with the Workspace Switcher at the top).
- Personal workspace — your own projects, your own sending.
- Team workspace — shared projects and sending history for a team or a client.
Rule of thumb: one workspace per team or client, one project per sending domain inside it.
2. The four roles
| Role | What they can do |
|---|---|
| OWNER | Everything — transfer/delete the team, manage members, manage projects |
| ADMIN | Update team info, manage projects and settings |
| MEMBER | Edit content — create and run tasks, templates, contacts |
| VIEWER | Read-only — can see projects, tasks, and results but not change them |
Permissions are enforced server-side per project: VIEWER can view, MEMBER and above can edit, ADMIN and above can delete.
3. Create a team and invite members
- Open the Workspace Switcher and choose Create Team.
- Name the team — GQ CRM creates a team workspace (and a default project, if your plan's project quota allows).
- Invite members with a role (OWNER / ADMIN / MEMBER / VIEWER).
- Members switch into the team workspace with the Workspace Switcher.
Plan note: Starter includes up to 3 team members; Pro includes unlimited members. If the team is at its member cap, upgrading Pro removes the limit.
4. Project permissions in practice
Inside a team workspace, projects inherit the team's role model:
- VIEWER on a project — can read config and history, can't change anything.
- MEMBER — can edit templates, create tasks, update SMTP config, and regenerate API keys.
- ADMIN — can also delete projects and manage team settings.
- OWNER — can delete or transfer the team itself (ownership transfers go OWNER → ADMIN only).
API key rotation (POST /api/projects/[id]/regenerate-key) requires edit permission — a VIEWER can't rotate a key, which keeps credentials in the hands of people who manage the integration.
5. The agency pattern
For agencies running multiple clients, the pattern is:
- One team workspace per client — contacts, tags, projects, and history stay isolated; cross-client data is never visible.
- One project per sending domain inside that workspace — reputations never mix.
- Per-project API keys — each client integration gets its own key; a leaked key exposes only that client's domain and can be rotated without touching others.
- OWNER/ADMIN for the agency, MEMBER/VIEWER for the client — the client can see their campaigns (VIEWER) or run them (MEMBER) without admin control.
6. Billing and usage
- The subscription belongs to the personal workspace; team workspaces share the owner's plan quota dynamically.
- Usage is counted across the owner's personal + all created team workspaces combined.
- Overage draws from the owner's credits balance first (one-time credits never expire; see billing docs).
Troubleshooting
- Can't see a project — check your active workspace (Workspace Switcher); projects are workspace-scoped.
- "No permission" on edit/delete — your role on that team is VIEWER (or you're in the wrong workspace); ask an ADMIN to raise your role.
- Can't delete a team — only OWNER can, and only when all projects are deleted first (soft-deleted projects block it).
- Team at member cap — Starter caps at 3 members; upgrade to Pro for unlimited.
Workspaces turn GQ CRM from a single-sender tool into a multi-client operation. One workspace per client, one project per domain, per-project keys — and the permission model keeps everyone in their lane.