# Security Tree Administration The _Security Tree_ object class allows Admins to control access to object records based on a hierarchical structure, similar to a tree. Admins can assign users and records to nodes within a security tree to provide record-level access. User application role access can cascade down through a hierarchy while visibility to object records can roll up through a hierarchy. For example, in the diagram below, VernBio's sales team is organized by a CEO, Sales VP, Territory A, and Territory B. Each point in the hierarchy is considered a security tree node. In this structure, _Sales VP_ is a child node of _CEO_, and _Territory A_ and _Territory B_ are child nodes of _Sales VP_. Sales Reps (users) are assigned to the _Territory A_ and _Territory B_ nodes with application roles. Diagram 1 Customer accounts (object records) are also assigned to the _Territory A_ and _Territory B_ nodes. Once a user is assigned into a security tree via a node, they gain the specified application role access to records assigned to the same node, or any child nodes. In the diagram below, _Sales Rep 1_ is granted _Viewer_ access to customer accounts assigned to _Territory A_, and _Sales Rep 2_ is granted _Editor_ access for customer accounts assigned to _Territory B_. Users assigned to the _CEO_ node receive similar access to customer accounts assigned to the _CEO_ node in addition to customer accounts assigned to the _Sales VP_, _Territory A_, and _Territory B_ nodes. The same behavior applies to the _Sales VP_ node, but users assigned to this node will not have access to customer accounts assigned to the _CEO_ node. Diagram 2 You can use _Security Tree_-class objects in conjunction with existing security controls on an object or object records, such as custom sharing rules, matching sharing rules, manual assignments, and **Atomic Security**. ## Configuring a Security Tree {#configuring-security-tree} When creating a custom object, select _Security Tree_ as the object class. There are two (2) additional fields specific to only the _Security Tree_ object class: * **User Tree Assignment Object Name**: This name is assigned to the automatically generated object with the [_User Tree Assignment_][1] object class applied. Once created, you cannot change this name. However, you can modify the label and plural label. This field is required. * **Restrict Users to a Single Node Assignment**: Allows you to restrict users to one (1) node within the security tree. Enabling this field allows you to leverage the [_User Reference Assignment_][4] field to automatically assign object records to the _Security Tree_. This field is optional. Once saved, Vault creates a raw object with the _User Tree Assignment_ object class applied to capture application role assignments for users within the _Security Tree_. Once the _Security Tree_-class object is created, you can secure additional objects and their records within your security tree. When you create or edit a custom object, the _Details_ tab contains a _Security Tree Object_ field that displays all _Security Tree_-class objects in your Vault. Select a _Security Tree_ and then enter a **Tree Assignment Object Name**. Once you save the secured object, Vault creates the raw object with the [_Secured Record Tree Assignment_][2] object class applied and the name you entered. This object allows you to provide users record-level access via the _Security Tree_. In addition, if [_Restrict Users to a Single Node Assignment_][3] is enabled on the selected security tree, the [_User Reference Assignment_][4] drop-down becomes available in the secured object's _Details_ section. Objects with the _User Tree Assignment_ or _Secured Record Tree Assignment_ class are system-managed and cannot be created in Vault.
### Secured Record Lifecycle {#secured-record-lifecycle} When a lifecycle is not configured on a secured object, only the following standard application role assignments from the security tree are evaluated at runtime: _Owner,_ _Editor_, _Viewer_. Once the lifecycle is configured, custom application role assignments within the object's lifecycle are applied to the security tree. Users gain implicit _Read_ permission to records assigned to their node or child nodes. If a user is assigned a custom application role with no permissions in the secured object's lifecycle, the user only receives _Read_ permission to any records assigned to their node or child nodes. If the custom application role is not configured on the secured object, any permissions on the role are not applied in the security tree as the role is not considered valid. Vault considers an application role assignment in a security tree valid only if it is standard (_Owner_, _Editor_, or _Viewer_) or a custom application role enabled within the secured object's lifecycle. When assigning users to custom application roles, it is recommended to grant these roles _Read_ permission within their corresponding secured object's lifecycle. This action reflects the implicit _Read_ permission granted through the security tree.
## How to Create Security Tree Nodes {#create-security-tree-nodes} To create a security tree node: 1. Create a record on the _Security Tree_-class object. 2. Enter a **Name** for the node. 3. Optional: Select a **Parent Node**. Only one node on the security tree is allowed to not have a parent node. This node is considered the root node. 4. Click **Save**. The security tree node is now created. Repeat this process to add additional nodes to the security tree. Users gain direct application role access to object records assigned to their node and its child nodes. For example, in the image below, Mike Viewer has _Viewer_ access to any records assigned to the _Vendor Management_ node as well as its child node _Vendor Record_. Mike Reviewer also has _Editor_ access to the _Vendor Record_ node, providing him _Editor_ and _Viewer_ access to records on this node. User Tree Assignment Example 1 ### Deleting a Security Tree {#delete-security-tree} Deleting a _Security Tree_-class object deletes any corresponding objects with the _User Tree Assignment_ or _Secured Record Tree Assignment_ object class applied. If records exist on the _User Tree Assignment_-class or _Secured Record Tree Assignment_-class object, you must delete those records before deleting the security tree. This same behavior applies to removing a security tree from a secured object. ### Deleting a Security Tree Assignment {#delete-security-tree-assignment} Deleting a user from a node removes the user's access to any records on the node and its child nodes. Deleting a record from a node only removes the user's access and visibility to the record on that node. However, deleting a user or record from a node does not impact additional security configured on the record. For example, if Mike Reviewer has access to Record 1 on the _Vendor Record_ node through custom sharing rules, the user does not lose custom sharing rule access if the record is deleted from the node. ## Static Assignments {#static-tree-assignment} A static assignment refers to manually assigning a user to a _Security Tree Node_ through the _User Tree Assignment_-class object or assigning a record to a node through the _Secured Record Tree Assignment_-class object. Records created on objects with these classes applied store the static assignments within the _Security Tree_.
### User Tree Assignment {#user-tree-assignment} Objects with a _User Tree Assignment_ object class allow you to assign a user to a node in a security tree with an assigned application role. To use this object to assign a user to a security tree node: 1. Create a record on the _User Tree Assignment_-class object. 2. Select the status as **Active** or **Inactive**. 3. Optional: Select a **Security Tree Node**. Although this field is optional, you must select a **Security Tree Node** to assign the user to it. 4. Select a **User** to assign to the **Security Tree Node** selected above. 5. Select the user's **Application Role**. 6. Optional: Enter an **External ID**. 7. Click **Save**. The user is now assigned to the _Security Tree Node_. You can assign the user to additional nodes if _Restrict Users to a Single Node Assignment_ is not enabled. In the image below, Mike Reviewer is assigned to the _Territory A_ node with _Editor_ access to any records assigned to the node and its child nodes. Justine Viewer is assigned to the _Territory B_ node with _Viewer_ access to any records assigned to the node and its child nodes. User Tree Assignment Example 2 ### Secured Record Tree Assignment {#secured-record-tree-assignment} Objects with a _Secured Record Tree Assignment_ object class allow you to assign object records to a _Security Tree_. Objects with this class are available only if you secured an object by selecting a security tree on the object's Details tab. To use this object to assign an object record to a _Security Tree Node_: 1. Create a record on the secured object. 2. Create a record on the _Secured Record Tree Assignment_-class object. 3. Select the status as **Active** or **Inactive**. 4. Optional: Select a **Security Tree Node**. Although this field is optional, you must select a **Security Tree Node** to assign the record to it. 5. Optional: Select a **Secured Record**. This field populates all records created on the secured object. 6. Optional: Select an **External ID**. 7. Click **Save**. The object record is now assigned to the _Security Tree Node_. Any users assigned to this node will gain access to the record based on their assigned application role. In the image below, object records _Customer Account A_ and _Customer Account B_ are assigned to the _Territory A_ node and _Customer Account C_ and _Customer Account B_ are assigned to the _Territory B_ node. Secured Record Tree Assignments Example ### Single User Tree Assignment {#single-user-tree-assignment} A single user assignment refers to restricting a user to only one node in the _Security Tree_. You must enable _Restrict Users to a Single Node Assignment_ on the _Security Tree_-class object to use this functionality. Once enabled, you can use the _User Reference Assignment_ field when securing an object by a _Security Tree_. If the _User Reference Assignment_ field on a secured object contains a value, you cannot clear this checkbox. This setting is available only if no static assignments exist for users on the _Security Tree_. Single User Tree Assignment Example ### User Reference Assignment {#user-reference-tree-assignment} A user reference assignment refers to automatically assigning records to a _Security Tree_ based on an existing static user assignment. When creating a secured object, you can select any user reference field on the secured object from the _User Reference Assignment_ drop-down. Then, when you create a record on the secured object, you can select a user from the user reference field. Once the record is saved, Vault automatically assigns the object record to the selected user's node. If the selected user is not assigned to a node, Vault creates the record but the assignment does not occur. In this case, the record is not visible to the user in Vault. User reference assignment applies to future records and not existing ones. In addition, previous record assignments created through user reference assignment are not impacted. However, it is recommended to remove users from these assignments so that previous application role access is removed on records prior to selecting a new user reference assignment field. User Reference Assignment Field Example ## Limits {#security-tree-limitations} The following limits apply to objects with a _Security Tree_ object class: * Up to one node without a parent, or root node, is allowed per _Security Tree_. * Up to ten levels of parent node-child node relationship allowed. * Up to 50,000 nodes are allowed per _Security Tree_. * Up to 70 objects can be secured by a _Security Tree_. * You can assign a single user to 100 nodes in a _Security Tree_. * You can assign a single object record to 200 nodes in a _Security Tree_. * You cannot select the _Security Tree_ object class if _Replicate sharing settings from parent object_ is enabled on the object. * If a parent object is secured by a _Security Tree_, you cannot modify _Security Tree_ configurations on the child object if _Replicate sharing settings from parent object_ is enabled. * Object types are not supported. * Only standard data store is supported. * You cannot create custom fields or enable object lifecycles on _User Tree Assignment_-class objects and _Secured Record Tree Assignment_-class objects. [0]: #static-tree-assignment [1]: #user-tree-assignment [2]: #secured-record-tree-assignment [3]: #single-user-tree-assignment [4]: #user-reference-tree-assignment [5]: #secured-record-lifecycle