> 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-posture-management/onboard-and-configure/post-deployment-steps/manage-user-roles-and-access-management/manage-access-to-objects/manage-access-to-report-templates.md).
# Manage access to report templates
The **Report Templates** page serves as the central repository where you can view, create, and modify report templates for your reports. By using object-level access, you can ensure that custom (user-defined) report templates, such as those used for specialized department metrics or sensitive internal audits, are only accessible to authorized users and user groups. Your access is determined by your role permissions combined with report template ownership; you can only interact with report templates where you are the Owner, report templates explicitly shared with you (or your user group), or report templates marked as **Public**.
{% hint style="warning" %}
### Prerequisite
* **Configure tenant-level settings**: An administrator must first establish the sharing framework under **Settings** → **Configurations** → **Access Management** → **Objects**.
The configuration of these settings defines the authorized sharing workflows for all custom objects, including report templates:
* **Enable "Owners can Share objects they created"**: Grants owners the ability to share report templates with specific users, user groups, and API keys. This enables the **Share** option in the right-click menu for any report template listed on the **Report Templates** page.
* **Disable "Owners can Share objects they created"**: Restricts owners to managing only **General access** (**Public** vs. **Restricted**). In this case, the **Share** option is removed from the report template menu on the **Report Templates** page and is replaced with the **Manage Access** option.
For more information on configuring tenant-level settings, see [Manage access to objects](/cortex-cloud-posture-management/onboard-and-configure/post-deployment-steps/manage-user-roles-and-access-management/manage-access-to-objects.md).
* **Define Scope-Based Access Control (SBAC)**: While per-object access controls the visibility of the report template itself, the underlying data in generated reports remains governed by SBAC. The scope of a generated report is based on the scope of the user who last saved the report template. Ensure the report template creator or last editor has the appropriate data permissions to provide intended results for all report recipients. For more information on defining SBAC, see [Manage user scope](/cortex-cloud-posture-management/onboard-and-configure/post-deployment-steps/manage-user-roles-and-access-management/manage-user-scope.md).
{% endhint %}
Understanding report behavior
Because report templates are used to generate static report instances, it is important to understand how access is applied:
* **Generated reports is the same as report template access**: A user can access specific report instances generated from a report template to which they have at least **Viewer** access. Access to report instances is the same as the access to the report template used to generate them; if a user is granted access to a report template, they gain access also to all reports previously generated from it. Conversely, if access to the report template is removed, the user immediately loses access to those reports.
* **Data scoping**: Data in reports is generated based on the scope of the user who last saved the template. If an Owner leaves the organization, an Administrator must Change Owner to ensure reports continue to generate data correctly based on an active user's scope.
* **Inherited widget access**: Reports can include both **Public** and **Restricted** widgets. When a widget is added to a report template, the resulting generated report will display the data from that widget to all authorized report recipients, even if they cannot see that specific widget in their own Widget Library.
Change owner of a report template
To ensure continuity when personnel changes occur or to hand off management of a resource, administrators can change the ownership of custom report template objects.
{% hint style="info" %}
### Note
Only Account Admins and Instance Administrators have the authority to change the owner of an object.
{% endhint %}
When changing ownership, keep the following in mind:
* **Principals**: Ownership can only be transferred to an individual **User**. You cannot assign a User Group or an API Key as the Owner of a report template.
* **Schedules**: When ownership is transferred, any existing report schedules associated with the report template are automatically removed. The administrator performing the transfer will see a confirmation message, and the new Owner will receive a notification in the Notification Center. The new Owner must manually redefine the schedule to resume automated report generation.
1. Select **Dashboards & Reports** → **Report Templates**.
2. Right-click the custom report template in the table and select **Change owner**.
3. Select the new owner from the list of users, and click **Change**.
How to configure access to report templates
**Step 1: Set role-level permissions**
Role permissions define the functional capabilities for report templates and determine what actions a user can take.
1. Select **Settings** → **Configurations** → **Access Management** → **Roles**.
2. Right-click the relevant user role, and select **Edit Role**.
3. Under **Components**, expand **Dashboards & Reports**, and locate **Reports**.
4. Configure access state:
* **Disabled**: Users cannot navigate to the **Report Templates** or **Reports** pages. Report templates cannot be shared with this role.
* **Enabled**: Allows report templates to be accessed and managed according to defined sub-permissions.
5. If **Enabled**, assign specific capabilities:
* **Create Reports**: Enables the **New Template** button, allowing the user to create new custom report templates. The user who creates the report template is designated as the **Owner**.
* **Edit Public Reports**: Allows the user to modify custom report templates set to **Public**, even if they are not the **Owner**.
6. Click **Save**.
**Step 2: Manage sharing for a report template**
Once a custom report template exists, the Owner (or an authorized Editor) defines its visibility.
1. Select **Dashboards & Reports** → **Report Templates**.
2. Locate the custom report template you want to share in the table.
3. Right-click the custom report template and select the available access option. The menu option you see depends on your tenant-level settings:
* **Share**: Use this if your admin enabled sharing. It allows you to grant access to specific users/groups and change the **General access** (**Public**/**Restricted**).
* **Manage Access**: Use this if sharing is disabled. It is a restricted view that only allows you to toggle the **General access** between **Public** and **Restricted**. You cannot grant access to specific individuals.
4. (If sharing is enabled) Search for the **User**, **User Group**, or **API Key** and assign the access level: **Viewer** (read-only) or **Editor** (can modify and share).
5. Set the **General access** state:
* **Restricted** (default): Private to the Owner and specifically invited principals.
* **Public**: Visible to all users who have the **Reports** component enabled in their role.
6. Click **Save**.
Sharing icons for report templates
The following icons help you identify the security access of report templates in the table on the **Report Templates** page:
* : A **Restricted** report template you created that is not shared with anyone else.
* : A report template you created that is currently shared with other users, user groups, or API keys.
* : A report template created by another user that has been shared with you.
* : A standard system report template provided by Palo Alto Networks. These are always **Public**, read-only, and cannot be deleted or edited, and their ownership cannot be transferred. Yet, you can **Duplicate** a system report template to create a custom version that you can then modify and share.
Import and export report templates
You can move report templates between different Cortex XSIAM tenants using the import and export functionality. Access and ownership are handled as follows during this process:
* **Export**: To export a report template, you must have at least **Viewer** access to that report template. The exported file contains the configuration of the report template but does not include the original access list or ownership data.
* **Import**: When you import a report template into a tenant:
* **New report template**: If the report template does not already exist in the tenant, you are automatically designated as the **Owner**.
* **Default access**: The report template is created with **Restricted** General access by default, regardless of its setting in the original tenant.
* **Existing report template**: If the report template already exists in the system, the imported template will be updated (overwriting the template definition), but the current **Owner** and access configuration remain unchanged.
---
# 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-posture-management/onboard-and-configure/post-deployment-steps/manage-user-roles-and-access-management/manage-access-to-objects/manage-access-to-report-templates.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.