> For the complete documentation index, see [llms.txt](https://cortex-docs.paloaltonetworks.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://cortex-docs.paloaltonetworks.com/cortex-cloud-runtime-security/cases-and-issues/overview-of-cases/overview-of-case-teams-and-roles.md).
# Overview of case teams and roles
You can assign individual users and entire user groups to specific roles within a case team. For sensitive or high-risk cases, you can restrict access to a case so that only assigned case team members can see or take action.
For more information, see [Assign a case team and restrict access](/cortex-cloud-runtime-security/cases-and-issues/analyze-and-resolve-cases/additional-case-actions/assign-a-case-team-and-restrict-access.md).
### Key benefits of case teams
Assigning a case team is beneficial for:
* **Staging team assignment prior to final ownership:** Engage multiple users and user groups early in the process, allowing team members to collaborate and evaluate the case before assigning a single final owner.
* **Defining clear roles and responsibilities:** Establish clear boundaries and ownership for everyone involved in the case.
* **Restricting access to sensitive or high-risk cases:** Assign specific team members and user groups, and restrict case access so that only the defined team can view it.
* **Coordinating multi-team efforts:** Smoothly coordinate tasks when multiple distinct teams are involved in an investigation.
### Case team roles
You can assign the following roles within a case team. These roles serve as labels to indicate a team member's level of involvement and do not grant additional permissions or access.
For the Collaborator and Watcher roles, you can assign individual users or user groups.
Role
Description
Assignee
The primary owner responsible for managing and resolving the case.
Collaborator
Team members actively assisting with specific case tasks.
Watcher
Users who need to monitor case updates but aren't directly assigned to tasks.
## Case access and visibility
You can control case visibility by adjusting a case’s **General Access** settings under **Manage case team**. By default, visibility is set to **Case Scope**.
### **Case Scope (Default)**
* **Organization-wide access:** Any user in the organization with the appropriate Scope-Based Access Control (SBAC) scope can view the case.
* **Permission requirements:** Users still require the appropriate Role-Based Access Control (RBAC) permissions to view, edit, or execute playbooks and automations.
### **Team Only**
Restricts case access exclusively to assigned team members.
* **Access Control:** Only assigned case team members can view or take action on the case.
* **Assigned team:** A case must have assigned collaborators or watchers before it can be set to **Team Only**. If a **Team Only** case has no assigned team members, its access automatically reverts to **Case Scope**.
* **Management rights:** Once a case is set to **Team Only**, only existing team members can add or remove watchers and collaborators.
* **SBAC requirements:** Team members gain full access to the case itself. However, access to underlying case data and related objects (such as issues and assets) remains strictly governed by their assigned SBAC role.
* **RBAC requirements:** Team members must still hold the necessary RBAC permissions to view, edit, or run playbooks and automations on the case.
* **Admin access rights:** Users with the **Instance Admin** and **Account Admin** roles cannot be scoped out of cases. They bypass both Case Scope and Team Only restrictions and will always have full access to all cases.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://cortex-docs.paloaltonetworks.com/cortex-cloud-runtime-security/cases-and-issues/overview-of-cases/overview-of-case-teams-and-roles.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.