# Admin Console
Generated: 2026-09-13T04:32:42.234Z
Source build: local
Canonical docs: https://teammately.ai/docs
---
id: admin-console.overview
title: Admin Console
summary: Understand the organization-level administration surfaces available at admin.teammately.ai.
kind: reference
product_area: admin_console
status: stable
updated: 2026-09-07
canonical: /docs/admin-console
---
# Admin Console
The current Teammately product exposes the Admin Console as a workspace-administration mode under `/admin`. Use this page to distinguish organization-level administration from project-level correctness work in the project workspace. The shared product shell switches between project navigation and workspace administration while preserving the organization-level boundary.
> Administration boundary
>
> Use the Admin Console for organization controls. Use project and benchmark workspace docs for Cases, Expert Contributions, Policies, Rubrics, coverage, evaluations, and improvement evidence.
## Definition
The Admin Console groups organization administration into Directory, Security, Insights, and Organization Settings. The code-backed navigation includes Members, Groups, Roles & Permissions, Domain Control, IP Address Control, Audit Log, Usage Statistics, Profile, Support Settings, Integrations, and API Keys.
This page documents that those surfaces exist. It does not claim detailed compliance, billing, deployment, rate-limit, or security behavior unless a linked source file exposes that behavior directly.
The Admin Console is the organization administration surface. Group management is separate from project-level correctness work.
The Integrations screen shows notification and partner connection surfaces that belong to organization administration. Visible contact-support states should not be documented as self-serve integrations.
API Keys are managed in the Admin Console and should be documented as an organization administration surface, separate from project correctness artifacts.
> API key boundary
>
> Creating an API key establishes a credential; it does not make every internal endpoint a supported customer API. Endpoint availability, bearer authentication, required scopes, request and response schemas, and error behavior belong to the versioned Public API contract.
## Fields, states, or lifecycle rules
- Members and Groups are organization directory surfaces. Project-level membership and project permissions remain separate surfaces in the main product.
- Roles & Permissions in the Admin Console manage workspace roles and permission keys exposed by the admin application. Do not treat role names in orientation pages as exact permission contracts.
- Domain Control stores whether domain enforcement is enabled and which email domains are allowed for invitation.
- IP Address Control stores whether IP limiting is enabled and the configured allowlist.
- API Keys can be listed, created, copied at creation time, scoped, and deleted from the admin app surface. Treat the full value as a secret and create separate keys for separate integration boundaries.
- Slack is the currently clickable self-serve notification integration in the Admin Console. Microsoft Teams and the other listed partners are visible as contact-support or coming-soon surfaces in the current integrations index, so these docs should not describe them as self-serve integrations.
- Audit Log and Usage Statistics appear as admin console surfaces, but this page does not promise exact event schemas, retention periods, analytics definitions, or export behavior.
Domain Control and IP Address Control are organization-level security settings. They should not be described as project review or benchmark approval mechanisms.
IP Address Control exposes enforcement settings and should be documented only as an admin access-control surface.
## Product boundary
Use the Admin Console when the question is about organization access, security controls, API keys, notification integrations, or organization-level activity. Use project settings and product-area docs when the question is about cases, reviews, policies, rubrics, benchmarks, and project-specific permissions.
A reviewer persona, a Project member, a Workspace role, and an organization administrator are related but not identical. Read each access or authority claim from its owning surface.
Likewise, an API key, its Project access, and an endpoint's action scope are related but not identical. Key administration belongs here; the external service contract must define what a caller can actually do.
## Source confidence
Code-backed: this page is grounded in the current `/admin` workspace route, shared navigation mode, admin directory, integrations index, and representative admin route implementations listed in the frontmatter source_refs.
## Related task pages
{% related-card-grid title="Related task pages" %}
- [Manage Project Members](/docs/project-settings/project-members)
- [Resolve an IP access restriction](/docs/troubleshooting/authentication)
- [Troubleshoot permissions](/docs/troubleshooting/permissions)
{% /related-card-grid %}
## Related reference pages
{% related-card-grid title="Related reference pages" %}
- [Workspace administration](/docs/governance/workspace-administration)
- [Roles and permissions](/docs/governance/roles-and-permissions)
- [Permissions](/docs/reference/permissions)
{% /related-card-grid %}
---
id: governance.workspace-administration
title: Workspace Administration
summary: Administer workspace and project boundaries so correctness work has clear ownership and scope.
kind: reference
product_area: governance
status: stable
updated: 2026-09-07
canonical: /docs/governance/workspace-administration
---
# Workspace Administration
## Definition
Workspace Administration covers two code-backed layers:
- Organization administration in the Admin Console, including members, groups, roles, domain control, IP address control, audit log, usage statistics, profile, support settings, integrations, and API keys.
- Project administration in the main product, including project members, groups, and project permission assignments.
Keep these layers separate when writing or operating from the docs. A workspace-level admin control is not the same as a project-specific correctness workflow.
Organization groups belong to the admin layer. Project membership and correctness artifact ownership remain separate concepts.
## Fields, states, or lifecycle rules
- Project permissions in the main product are code-backed for user and group subjects with `ADMIN` or `MEMBER` project roles.
- The Admin Console exposes additional organization-level controls such as roles, domain control, IP address control, integrations, and API keys.
- Do not infer compliance status, retention rules, SSO behavior, billing behavior, rate limits, or deployment options from the existence of an admin screen.
- Approval actions in correctness workflows require accountable ownership; AI suggestions do not approve themselves.
## Related objects
Related objects may include workspace members, groups, workspace roles, permission keys, project permission assignments, domain controls, IP controls, API keys, notification integrations, and the project artifacts those people can access.
{% example-demo title="Human approval boundary" %}
A Workspace administrator manages an organization group in the Admin Console. A Project owner then grants that group access under Project Settings. The group can inspect the Project according to the current Project membership surface, but this does not change organization security controls or create authority over every governed correctness artifact.
{% /example-demo %}
## Source confidence
Code-backed: this page is grounded in the Admin Console navigation and the main product project settings routes listed in source_refs.
## Related task pages
{% related-card-grid title="Related task pages" %}
- [Request an Expert Contribution](/docs/expert-contributions/request-contribution)
- [Manage Project Members](/docs/project-settings/project-members)
- [Import and prepare cases](/docs/operating-manual/import-and-prepare-cases)
{% /related-card-grid %}
---
id: governance.roles-permissions
title: Roles and Permissions
summary: Use roles and permissions to route ownership, review, and approval work clearly.
kind: reference
product_area: governance
status: stable
updated: 2026-09-07
canonical: /docs/governance/roles-and-permissions
---
# Roles and Permissions
## Definition
Roles and Permissions covers the access controls visible in the current product source. It is not a generic enterprise RBAC promise.
The main product exposes project permission management for users and groups. The Admin Console exposes workspace role management and permission keys. Orientation pages may describe common personas such as product owner, reviewer, expert, AI engineer, or administrator, but those personas are not exact permission values unless a code-backed source says so.
Use the roles table for organization access claims, and use project permission pages for project-level access claims.
## Fields, states, or lifecycle rules
- Main-product project permissions use user or group subjects and code-backed `ADMIN` or `MEMBER` project roles.
- Admin Console roles are workspace roles with permission keys managed through the admin app.
- Reviewer assignments and review ownership are workflow concepts; they should not be treated as workspace role names.
- Approval actions require accountable ownership; AI suggestions do not approve themselves.
## Related objects
Related objects may include workspace users, workspace groups, workspace roles, permission keys, project permission assignments, reviewer assignments, review sessions, approvals, and the correctness artifacts those users can access.
{% example-demo title="Human approval boundary" %}
A domain expert receives a Contribution and can complete its assigned Tasks. The same person is also a member of one Project, so they can inspect that Project's permitted surfaces. Neither fact makes them an organization administrator or grants authority to approve every governed artifact. Read access, Contribution assignment, artifact approval, and Workspace administration from their owning surfaces.
{% /example-demo %}
## Source confidence
Code-backed: this page is grounded in the main product project permission routes and Admin Console role management source listed in source_refs.
## Related task pages
{% related-card-grid title="Related task pages" %}
- [Request an Expert Contribution](/docs/expert-contributions/request-contribution)
- [Build policies and rubrics](/docs/operating-manual/build-policies-and-rubrics)
- [Manage Project Members](/docs/project-settings/project-members)
{% /related-card-grid %}
---
id: reference.permissions
title: Permissions
summary: Understand the user-facing permission boundaries for projects, reviewers, settings, and expert UI access.
kind: reference
product_area: reference
status: stable
updated: 2026-09-07
canonical: /docs/reference/permissions
---
# Permissions
## Definition
Permissions describe the user-facing access boundaries that affect projects, reviewer work, settings, Expert UI access, and organization administration. Use this page to decide which access surface to inspect before diagnosing a blocked workflow.
This reference does not turn role labels into a complete public permission matrix. Exact permission behavior should stay tied to source-backed pages and the admin or project surfaces that expose it.
## Fields, states, or lifecycle rules
- Project access affects cases, standards, coverage, benchmark work, and project settings.
- Reviewer access affects assigned expert work and reviewer-facing surfaces.
- Organization administration affects members, groups, roles, security controls, API keys, and integrations.
- Role labels in docs should be treated as understandable operating labels, not as exhaustive permission contracts.
- Do not infer auth, security, compliance, tenant isolation, or billing guarantees from this reference.
## Related objects
Permissions should be read with [Admin Console](/docs/admin-console), [Workspaces and projects](/docs/concepts/workspaces-projects), [Permissions troubleshooting](/docs/troubleshooting/permissions), and [Reviewer and project access](/docs/governance/reviewer-and-project-access).
{% example-demo title="Permissions boundary" %}
Symptom: A reviewer can sign in but cannot complete assigned case review.
Permission boundary: The issue may be reviewer assignment, project access, Expert UI routing, or missing case context.
Interpretation: Diagnose access and assignment before changing cases, standards, or benchmark evidence.
{% /example-demo %}
## Source confidence
Code-backed: Project, user, and workspace types plus Project Permissions and Members surfaces support the user-facing boundaries described here. They do not form an exhaustive authorization matrix; assignment, organization administration, and object approval remain separate product states.
## Related task pages
{% related-card-grid title="Related task pages" %}
- [Admin Console](/docs/admin-console)
- [Workspaces and projects](/docs/concepts/workspaces-projects)
- [Permissions troubleshooting](/docs/troubleshooting/permissions)
- [Expert UI](/docs/integrations/reviewer-workspace)
- [Product quickstart](/docs/quickstart)
{% /related-card-grid %}