Team Management

Talonic organizations use role-based access control (RBAC) with four hierarchical roles, Viewer, Member, Senior Member, and Admin, that govern who can view, create, edit, and manage resources across your workspace. Access control is enforced at the API level, so permissions apply consistently whether users interact through the web interface, the AI agent, or the public API.

Every user in your organization holds one of four roles that determine what they can see and do. Roles are hierarchical (ascending Viewer < Member < Senior Member < Admin): each level includes all permissions of the levels below it. Choose the most restrictive role that still lets a team member do their job. For most people working on data review and extraction, Member provides everything they need; give Senior Member to the reviewers who should decide fields your Specs mark as complex.

New members are added via domain matching: company email domains auto-match to your org with pending status requiring admin approval. This means anyone who signs up with an email from your company domain is automatically associated with your organization, but cannot access any data until an Admin explicitly approves them. Manage all team members and pending requests from Team Members in the user menu (/team). Each joiner receives the workspace's default join role, which is Viewer unless an Admin set a different default; workspaces that opt into automatic activation skip the pending step.

Senior Member exists for review work that needs experience. A Spec author can tag a field complex; only Senior Members and Admins can then approve, correct, or override that field, in the Review Queue and in Review Mode alike. Members still see the field and can leave a recommendation that a senior reviewer confirms with one click. Senior Members can also pin fields so they appear at the top of every Review Mode rail as standing context. The role grants nothing outside review: it cannot approve joiners, change roles, or edit workspace settings.

When a team member is removed, their access is revoked immediately but their past actions — edits, uploads, approvals, and review decisions — remain in the audit trail. This preserves data integrity and compliance history. Removed users can be re-added later through the same domain matching process if needed.

• Viewer — read-only access to documents, extraction results, schemas, and reports. Cannot create, edit, or delete any resources.
• Member (shown in the app as Contract Management) — full CRUD access to documents, schemas, jobs, matching configurations, and delivery bindings, and approve, correct, or override review items. On a field tagged complex, a Member can leave a recommendation for a senior reviewer instead of deciding. Cannot manage team members or workspace settings.
• Senior Member (shown in the app as Senior Contract Management) — all Member permissions plus deciding complex-tagged fields in the Review Queue and Review Mode, and pinning fields to the top of every Review Mode rail. It does not include member or role management.
• Admin — the top role: all Senior Member permissions plus field deprioritization rules, team management (approve/reject members, change roles), billing, API key generation and revocation, organization settings, and routing rules. Admins are co-equal (last-admin protection applies, and any admin can reset another admin). The role is stored internally as owner and displayed as "Admin".

1. Open Team Members from the user menu (bottom of the sidebar).
2. Review any pending members waiting for approval.
3. Approve or reject each pending member.
4. Assign the appropriate role based on their responsibilities.
5. Optionally, change roles later from the same Team page.

API Access and Roles

API key scopes are separate from team roles, but they work together to enforce access control. An API key created by an Admin can have any combination of scopes (extract, read, write, operations, billing, delivery), while team role permissions apply when members interact through the web interface or AI agent. For programmatic integrations, create dedicated API keys with the minimum required scopes rather than sharing a single key across all team members. This separation ensures that revoking a team member's access does not disrupt API-based workflows.

curl https://api.talonic.com/v1/documents \
  -H "Authorization: Bearer $TALONIC_API_KEY"

{
  "data": [
    {
      "id": "doc_7f3a1b2c",
      "filename": "invoice.pdf",
      "status": "completed",
      "document_type": "Invoice"
    }
  ],
  "pagination": {
    "total": 156,
    "limit": 20,
    "has_more": true,
    "next_cursor": "eyJpZCI6MTU2fQ"
  }
}

When onboarding a new team, a common pattern is to have an Admin create the workspace and set up API keys, then invite team members via domain matching. Admins handle day-to-day member approvals and role assignments, while Members focus on document processing and schema configuration. This separation of concerns scales well from small teams of two or three people to larger organizations with dozens of members across multiple departments.

For security-sensitive organizations, it is important to establish clear API key ownership practices. Only Admins can create and revoke API keys, which prevents team members from generating keys that might bypass role-based access controls. Each key should be labelled with the integration it serves (e.g., "BI Dashboard - Read Only", "ETL Pipeline - Extract") so that when a team member leaves or an integration is decommissioned, the corresponding key can be identified and revoked quickly without guessing which key belongs to which system.