> 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-xsoar-8-saas/multi-tenant/child-tenant-management/content-management-in-multi-tenant.md). # Content management in multi-tenant Content (including integrations) can be configured on the main tenant or child tenants. If creating content on the main tenant, you can push that content to child tenants. Usually, if the content applies to all child tenants, it should be configured on the main tenant and pushed to the child tenants. In some cases, you may need to configure an integration on the child tenant only. For example, the end-user has the information needed to configure a specific integration but does not want that information stored on the main tenant. Also, any integration that fetches incidents or indicators (feeds) must be configured on the child tenant, since incidents are not stored on the main tenant. **Content dependencies** Content that is synced from the Main Tenant, includes not just the content item but also dependencies. In Cortex XSOAR, there are multiple layers of dependency relationships. For example, a classifier depends on an incident type, an incident type depends on a layout, layouts depend on fields, and fields depend on scripts. For a basic example of content dependencies, see the **Phishing - Generic v3** playbook, which contains 43 scripts. The scripts are dependencies of the playbook, which needs them to execute properly. You can view playbook dependencies under the **Propagation Labels** field in the playbook **Settings**. When syncing content from the main tenant to child tenants, content includes these dependencies. {% hint style="info" %} ### Note Content dependencies are calculated recursively, so that if, for example, Playbook A uses Playbook B (dependency), which in turn uses scripts C and D (dependencies), all of the dependencies (Playbook B and scripts C and D) will be included along with Playbook A. {% endhint %} **Propagation labels** When syncing content from the main tenant, you can use propagation labels to decide what content to push and which child tenant you want to push content to. You can add propagation labels to the following: * Child tenants * Content items {% hint style="info" %} ### Tip We recommend that you first apply propagation labels to your child tenants and then add the corresponding labels to the content items that you want to sync to the child tenants. {% endhint %} For a content item to be synced to a child tenant, both the content and child tenant must have the same propagation label. For example, if you want Playbook ABC to sync to Tenant 123, they both need to have the same propagation label, such as **Premium**. Content is pushed to tenants by matching propagation labels. When creating or editing content, you can add the following propagation labels for syncing content to a child tenant: | Propagation label | Description | | ----------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | All | Content items with the **all** label are synced to all child tenants, regardless of whether the child tenants have labels. This is the default label for content items. | | Custom | Add custom labels by typing a label name in the **Propagation Labels** field when adding or editing a content item or when selecting the child tenant and clicking **Propagation Labels** on the **Tenant Management** page. | If an integration has the same settings for multiple child tenants, you can configure the integration on the Main Tenant and propagate it to multiple child tenants. For more information, see [Add propagation labels to a child tenant](#UUID-728acade-f6cf-c273-045e-499094bb45db). {% hint style="info" %} ### Note If a content item does not have any labels, it will not be synced to any child tenants. If a child tenant does not have any labels, only content items with the **all** propagation label will sync to it. If there is no propagation label on your content, for example, a script or playbook, but it is a dependency of a package that you propagate to a tenant, the unlabeled content is still synced to the tenant. If the content includes dependencies, these dependencies appear during the sync process, even if their propagation labels don’t match that of the tenant, as long as the labels of the parent content match the child tenant labels. {% endhint %} When using a remote repository with a multi-tenant deployment, the remote repository must be configured and a machine must be set as the development environment, before you can view propagation labels. For more information, see [Manage content using a remote repository](#UUID-2d1ba846-24b7-68ac-e38f-2d8b48169e11). The following example demonstrates how propagation labels work with content dependencies. The playbook has a `test` propagation label, which matches the child tenant's label, but the scripts contained within the playbook have a propagation label of **`test1`**, which differs from that of the playbook. **Playbook** ![playbook-propagation.png](/files/hgoJtTjMZT2E6eWKOOyp) **Script** ![script-propagation-label-8.png](/files/0r65lvd5UNyh2S8h1ABD) Even though the script propagation label does not match that of the tenant, the content is still propagated to tenants during the sync process. If there is no relevant propagation tag on your content, for example, a script or playbook, but it is a dependency of a package that you propagate to a tenant, the unlabeled content is still synced to the tenant. --- # 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-xsoar-8-saas/multi-tenant/child-tenant-management/content-management-in-multi-tenant.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.