---
sourceDocument: Australia Governance, Risk, and Compliance
sourceDocumentLink: https://www.servicenow.com/docs/r/australia/governance-risk-compliance
Release :
- australia
ft:locale :
- en-US
ft:publication_title :
- Australia Governance, Risk, and Compliance
ft:clusterId :
- grc
bundleId :
- grc
workflow :
- Technology
---
# Hierarchy relationship forms in Privacy Management
# Hierarchy relationship forms in Privacy Management {#ariaid-title1}
Release version: Australia
Updated August 19, 2026
 3 minutes to read
Summarize
 Summarized using AI
This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.
## Summary of Hierarchy relationship forms in Privacy Management
Hierarchy relationship forms in Privacy Management allow you to define how different nodes within your privacy data processing activities relate to each other.
This enables clear mapping of dependencies, data flows, and organizational structures in your privacy management framework, ensuring accurate tracking of personal data processing and transfers across your enterprise.
Show full answer Show less
## Define relationships form
When creating a new hierarchy relationship, you specify the primary record and primary node, which are typically the current processing activity or a linked node. You also define the primary node location, which is auto-populated from various sources but can be edited.
The **relationship type** defines how the primary node relates to the related node. Key built-in relationship types include:
* **Depends on:** Primary node cannot function without the related node (e.g., onboarding depends on identity verification).
* **Contains:** Primary node is a parent activity containing the related node as a sub-activity.
* **Contained by:** Inverse of Contains, automatically set on child nodes.
* **Sends data to:** Primary node transfers personal data to the related node.
* **Received data from:** Primary node receives personal data from the related node.
* **Used by:** Primary node is a shared resource used by related nodes without data exchange.
Note that **Sends data to** and **Received data from** should be used to capture personal data transfers accurately.
The **related node type** filters available nodes based on categories such as Business Application, Business Process, Company, or Vendor, making it easier to select the appropriate related node.
## Relationship details form
After defining the relationship, you provide additional details including:
* **Part of processing activity:** Indicates if the related node is part of the current processing activity (selected by default).
* **Related node location:** Auto-populated location for the related node, editable if needed.
* **Description:** Text description of the relationship.
* **Select data subject types involved:** For relationships involving personal data transfers (*Sends data to* or *Received data from*), specify which data subject types are involved, their locations, volume, and impacted data elements (e.g., home address, salary).
This detailed data subject information helps you understand and document the scope and specifics of personal data flows between nodes. Administrators can configure this data subject selection behavior for custom relationship types if needed.
When you create a new hierarchy relationship in Privacy Management, you first define how a node is related to another, and then provide details for each related node.
## Define relationships form {#new-relationship-forms__define-relationships-form}
{#new-relationship-forms__table_define_relationship_form__entry__2}
| Field | Description |
|-|-|
| Primary record | Processing activity you are currently working on. This field is automatically populated and cannot be changed. |
| Primary node | Node for which you are creating the relationship. By default, this field is automatically populated with the current processing activity. You can change it to another node that is already linked to the processing activity. |
| Primary node location | Location of the primary node. This field is automatically populated from the location set on the node. If the node location is not specified, the associated entity location is used. If that is not specified either, the associated CMDB record location is used. You can edit this field to change the value. |
| Relationship type | Relationship between the primary node and the related node. The built-in relationship types are: * Depends on: Primary node cannot function without the related node. For example, a customer onboarding processing activity depends on an identity verification application because onboarding cannot proceed without verifying a customer's identity. * Contains: Primary node is the parent activity that includes the related node as a sub-activity. For example, an employee management processing activity contains payroll processing and benefits enrollment as sub-activities. * Contained by: Inverse of the Contains relationship type. When you create a Contains relationship on a parent activity, the child activity automatically shows a Contained by relationship. For example, if an employee management processing activity contains payroll processing, payroll processing automatically shows a Contained by relationship to the employee management processing activity. * Sends data to: Primary node sends personal data to the related node. Use this relationship when personal data moves between entities, systems, vendors, or jurisdictions. For example, a payroll processing system in the US sends personal data about employees to an HR platform in the EU. * Received data from: Primary node is the recipient of personal data from the related node. For example, an HR platform in the EU receives personal data about employees from a payroll processing system in the US. * Used by: Primary node is a shared resource consumed by one or more related nodes, without any data flowing between them. For example, a customer database can be used by multiple marketing campaign activities to look up customer segments. {#new-relationship-forms__ul_owv_jpv_gkc} Note: Use Sends data to and Received data from when personal data moves between two nodes to capture data transfers. For more information, see [Manage data transfers](https://www.servicenow.com/docs/O6qxLjKbefYDv11GWBn99w "Organizations often transfer personal data between applications, vendors, business units, and regions, which are subject to privacy regulations. Privacy Management captures each movement as a data transfer record on the processing activity to help you comply with privacy regulations."). |
| Related node type | Type of record you are connecting to the primary node. The available related nodes are filtered based on the selected type. The built-in related node types are: * Business Application * Business Process * Business Service * Company * Entity * Processing Activity * Vendor {#new-relationship-forms__ul_c5p_ypv_gkc} For example, if you select Business Application, only business applications are available as related nodes. |
[ ]
{#new-relationship-forms__table_define_relationship_form}
## Relationship details form {#new-relationship-forms__relationship-details-form}
{#new-relationship-forms__table_relationship_details_form__entry__2}
| Field | Description |
|-|-|
| Part of processing activity | Option that marks the related node as part of the current processing activity. Selected by default. |
| Related node locations | Location of the related node. This field is automatically populated from the location set on the node. If the node location is not specified, the associated entity location is used. If that is not specified either, the associated CMDB record location is used. You can edit this field to change the value. |
| Description | Description of the relationship between the primary node and this related node. |
| Select data subject types involved | Details of the data subject types whose personal data is involved. For each data subject type, update the respective cells in the following columns: 1. Involved: Mark Yes or No to indicate whether their personal data is being transferred from the primary node to the related node. 2. Location: Specify all the locations that process personal data of this data subject type. 3. Volume: Specify the number of impacted data subjects. 4. Data elements: Specify which personal data elements are impacted. For example, home address, salary, work assignments. {#new-relationship-forms__ol_udc_5sv_gkc} By default, this field appears only when the selected relationship type is Sends data to or Received data from. However, a privacy admin can extend this behavior to a custom relationship type. For steps, see [Configure data subject selection in hierarchy relationships](https://www.servicenow.com/docs/USQYCWn6dH71~3wNMOBODg "Enable data subject selection in custom relationship types by configuring the sn_privacy.relationship_involving_data_subjects system property."). |
[ ]
{#new-relationship-forms__table_relationship_details_form}