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.