# IP access restriction Generated: 2026-09-13T04:34:28.427Z Source build: local Canonical docs: https://teammately.ai/docs --- id: troubleshooting.authentication title: IP access restriction summary: Resolve the current Access Restricted page when the detected IP is not on the Workspace allowlist. kind: error product_area: troubleshooting status: stable updated: 2026-08-23 canonical: /docs/troubleshooting/authentication --- # IP access restriction Use this when Teammately displays **Access Restricted** and says the current IP is not on the Workspace allowlist. Sign-in, Project membership, and Contribution assignment are separate problems. ## Symptom The page reports **Access restricted by IP** and shows a detected client-header IP, backend-detected IP, or both. ## Likely causes - The current IPv4 or IPv6 address is not on the Workspace allowlist. - A VPN, proxy, gateway, or network change caused the detected address to differ from the expected address. - The client-header and backend-detected addresses differ, so the administrator needs the value actually shown by the product. ## Diagnostic checks - Read both detected IP values shown on the page. - Confirm whether the user recently changed networks or enabled a VPN. - Copy the displayed address instead of relying on an address from another device or external lookup. - If the page no longer appears but Project content is still unavailable, continue with permissions troubleshooting. ## Fix - Send the displayed IP to the Workspace administrator. - Have the administrator add the required single address or CIDR in the applicable security settings. - Retry after the allowlist change is active. If the detected address changed again, resolve the network or VPN source before adding more entries. ## Prevention - Confirm the expected access network before time-sensitive Contributions or evaluations. - Prefer a stable organizational network path when the Workspace uses IP restrictions. - Keep IP restriction, Project membership, and Contribution assignment diagnoses separate. ## Related task pages {% related-card-grid title="Related task pages" %} - [Request an Expert Contribution](/docs/expert-contributions/request-contribution) - [Reviewing cases](/docs/expert-contributions/complete-contribution) - [Product quickstart](/docs/quickstart) {% /related-card-grid %} ## Related reference pages {% related-card-grid title="Related reference pages" %} - [Permissions](/docs/reference/permissions) - [Reviewer and project access](/docs/governance/reviewer-and-project-access) - [Workspaces, projects, and target systems](/docs/object-model/workspaces-projects-and-target-systems) {% /related-card-grid %} ## Source confidence Code-backed: the Access Restricted route displays the client-header and backend-detected IP values, provides copy controls, and directs the user to an administrator for allowlisting. This page does not claim a broader sign-in or authentication contract. --- 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 %} --- id: troubleshooting.permissions title: Permissions troubleshooting summary: Separate Project membership from Expert Contribution assignment and readiness when an expert has no tasks available. kind: error product_area: troubleshooting status: stable updated: 2026-09-07 canonical: /docs/troubleshooting/permissions --- # Permissions troubleshooting Use this when project role, reviewer assignment, or approval ownership prevents someone from completing the intended work. ## Symptom A user can access Teammately but cannot open the expected Project, or an expert reports **no tasks available** after opening their Contribution link. These symptoms belong to different owning surfaces. ## Likely causes - The user or group is not listed under **Project Settings → Project Members**. - The Contribution was requested for a different recipient. - The Contribution exists but its next Task or Checkpoint is not ready. - The current IP is blocked before Project membership is evaluated. ## Diagnostic checks - Confirm that the user or group appears in **Project Members** for the intended Project. - Open the Contribution from the sender-side Expert Contributions workspace and verify its recipient and status. - Check whether the expert has an executable Task or Checkpoint, not merely whether the Contribution exists. - If **Access Restricted** is visible, resolve the IP allowlist first. ## Fix - Add the correct user or group under **Project Settings → Project Members** when Project access is missing. - Correct the Contribution recipient through the owning Contribution workflow when the request went to the wrong person. - Resolve lifecycle or readiness problems in Expert Contributions when access succeeds but no Task can be entered. - Do not infer a permission from a role label or edit governed artifacts merely to make a control appear. ## Prevention - Separate reviewer access from approval authority in review setup. - Check assignments before launching a review session. - Use a small pilot Contribution before assigning a larger specialist cohort. - Keep project membership changes visible to review owners. ## Related task pages {% related-card-grid title="Related task pages" %} - [Request an Expert Contribution](/docs/expert-contributions/request-contribution) - [Reviewer assignments and statuses](/docs/expert-contributions) - [Using checkpoints](/docs/expert-contributions/complete-contribution) {% /related-card-grid %} ## Related reference pages {% related-card-grid title="Related reference pages" %} - [Permissions](/docs/reference/permissions) - [Roles and permissions](/docs/governance/roles-and-permissions) - [Expert Contributions](/docs/expert-contributions) {% /related-card-grid %} ## Source confidence Code-backed: Project Members and the redirected Project Permissions route define current Project access management; Contribution status and runtime navigation distinguish access from executable-task readiness. The Access Restricted route defines the separate IP boundary. --- id: concepts.workspaces-projects title: Workspaces and projects summary: Learn how Teammately organizes teams, projects, product goals, and access boundaries. kind: concept product_area: object_model status: stable updated: 2026-09-07 canonical: /docs/concepts/workspaces-projects --- # Workspaces and projects ## Definition The Workspace is the organization-level container. A Project is the operating boundary for one body of correctness work: its Project Agent Brief, Coverage Facets, Cases, Policies, Rubrics, Harnesses, Agent Setup, Project Settings, and Benchmarks. ## Why it matters The distinction matters because Workspace membership and Project participation are not interchangeable. A person can belong to the organization without having access to every Project, and a role label must not be treated as proof of a specific permission. ## Where it appears in the product Project Settings exposes General configuration, Regime, Input Schema, and Project Members. Organization-level administration belongs to the Admin Console. Benchmark work remains nested inside the selected Project and reuses that Project's governed objects. ## Artifacts it affects The boundary affects navigation, identifiers, membership, permissions, Project Agent Brief generations, Cases, governed standards, Harnesses, Benchmarks, Runs, and Contributions. Moving or copying artifacts between Projects is not implied by shared Workspace membership. ## Boundary check When a user cannot reach an object, confirm the Workspace, Project ID, Project membership, and object-specific assignment separately. When an artifact appears reusable across Projects, verify its source context, owner, and correctness boundary before recreating it. Shared organizational membership is never evidence that two Projects use the same Cases, standards, or Benchmark Versions. {% example-demo title="Same policy shape, different projects" %} One Workspace contains a billing-assistant Project and a security-assistant Project. The teams may use similar Rubric-writing practices, but their Project Agent Briefs, Cases, Policies, Harnesses, reviewers, and Benchmark evidence remain project-scoped. A user who can administer the billing Project is not assumed to have the same access in the security Project. {% /example-demo %} ## Related workflows {% related-card-grid title="Related workflows" %} - [Configure Project settings](/docs/project-settings) - [Manage Project Members](/docs/project-settings/project-members) - [Understand organization administration](/docs/admin-console) - [Troubleshoot permissions](/docs/troubleshooting/permissions) {% /related-card-grid %} ## Related reference pages {% related-card-grid title="Related reference pages" %} - [IDs and keys](/docs/reference/ids) - [Permissions](/docs/reference/permissions) - [Workspaces, Projects, and target systems](/docs/object-model/workspaces-projects-and-target-systems) - [Project Context](/docs/agent-setup/project-context) {% /related-card-grid %} ## Source confidence Code-backed: Workspace and Project types establish the container boundary; Project Settings, Members, and Permissions expose the current project-scoped configuration and access surfaces. Organization-level behavior is intentionally left to the separately bounded Admin Console documentation.