# Replicating Sharing Settings from Parent Object When a parent-child object relationship exists, you can enable the _Replicate sharing settings from parent object_ setting on the parent object reference field. This setting allows the child object to inherit the parent object's record-level security configuration, no matter how it was created (sharing rules, matching sharing rules, manual assignments, or a _Security Tree_). You can use this setting to control a user's access to a child object based on their access to the parent object.
## How to Replicate Sharing Settings from a Parent Object To replicate the sharing settings from a parent object to a child object: 1. Navigate to **Admin > Configuration > Objects > [Child Object] > Fields**. 2. Edit or create an object field that references a parent object. 3. Select **Replicate sharing settings from parent object**. 4. Click **Continue** on the **Enable Replicate Sharing Settings** dialog. This dialog displays a message stating that enabling this setting deletes any existing sharing rules on the child object. 5. Click **Save**. Once enabled, the child object acquires the roles assigned on the parent object. When viewing the _Sharing Rules_ tab on the child object, Vault displays a link to the parent object's _Sharing Rules_ tab. This link is also available in the child object's _Details_ tab in the _Dynamic Access Control_ field. Vault sends you a notification once the replication process is complete. You cannot clear _Replicate sharing settings from parent object_ until this process is complete. This setting is only available on parent object reference fields if record-level security is enabled on the parent object. In addition, this setting only supports up to two (2) levels of parent-child object relationships (for example, parent, child, and grandchild). A child object cannot replicate sharing settings from multiple parents at once. However, you can enable _Replicate sharing settings from parent object_ on all child and grandchild objects of a parent object. ## Object Lifecycle Configuration Only roles configured on the parent and child object lifecycles can replicate between both objects. You should configure these roles on the parent object and then the child object that will inherit role assignments. For example, if the parent object lifecycle contains the roles _Viewer_, _Editor_, _Owner_, _Reviewer_, and _Approver_ and the child object lifecycle contains _Viewer_, _Editor_, _Owner_, and _Reviewer_, the _Approver_ role cannot replicate from the parent object. Even if the _Approver_ role is included in the sharing settings on the parent object, it will not cascade to the child as it is not defined in the child object's lifecycle. In addition, object lifecycle permissions, such as Atomic Security, are not replicated from the parent object. For example, you could assign the _Approver_ role the _Editor_ permission on the parent object lifecycle and _Viewer_ on the child object lifecycle. The use of an object lifecycle is optional. If no object lifecycle exists on the parent or child, you can only replicate the standard _Viewer_, _Editor_, and _Owner_ roles. You must configure any additional custom roles and their permissions on the child and parent object lifecycle. ### Modifying Roles on the Object Lifecycle Modifications to the roles on the parent object lifecycle do not impact the same roles on the child object lifecycle. For example, if the parent and child object lifecycles include an _Approver_ role, deleting the _Approver_ role on the parent object lifecycle does not remove it from the child object lifecycle. However, modifying a role's _Read_ permission on the parent object changes the same role's _Read_ permission on the child object. You cannot edit the _Read_ permission on the child object. If the parent object is hidden in an object lifecycle state through a role's _Read_ permission, the child object is also hidden. In addition, you cannot delete a role from the child object lifecycle if it is in use in the parent object's sharing settings. The _Owner_ role on child object records is assigned to the _Owner_ on the parent object and cannot be modified. ## Workflow Configuration Object workflows that include a child object with _Replicate Sharing Settings from Parent Object_ enabled are impacted as follows: * If a workflow contains an _Update Sharing Settings_ step or a _Task_ step configured with an _Update Sharing Settings_ rule, Vault returns an error message when the workflow is activated. You can continue to edit and save the workflow, and include it in VPKs as needed. * If a workflow with an _Update Sharing Settings_ step or a _Task_ step configured with an _Update Sharing Settings_ rule is in progress when an included object is secured with parent object sharing settings, an error message prevents the workflow from progressing. You must cancel and restart the workflow with the _Update Sharing Settings_ step or rules removed. ## Limitations The following limitations apply when _Replicate sharing settings from parent object_ is enabled: * You cannot enable _Replicate sharing settings from parent object_ on an object with the _Security Tree_ object class enabled. However, if _Security Tree_ is enabled on the parent object, the child object can inherit roles assigned to the object through _Security Tree_ configurations. * You cannot directly share a child object's records using manual assignment on the child's sharing settings if it is replicating sharing settings from its parent object. * Sharing settings on the child object are read-only and cannot be modified through manual assignment. * If _Replicate sharing settings from parent object_ is enabled on a grandchild object, you cannot clear the setting on the immediate parent (child) object. Likewise, you cannot delete the parent object reference field on a child object if it has a child (grandchild) object with _Replicate sharing settings from parent object_ is enabled. * You cannot clear _Replicate sharing settings from parent object_ if you just enabled it. When this setting is enabled, Vault performs an internal operation to clean up resources and does not allow clearing the setting until the process is complete.