# Copying Object Records Copying records provides significant time savings, allowing you to quickly create a large number of similar object records. When copying from objects with child or grandchild relationships, you can often choose to copy the entire hierarchy of records. For example, the _Product_ object is the parent of the _Marketing Campaign_ object. When copying the _CholeCap_ product record, you can copy its marketing campaigns as well, meaning that the single copy action could create multiple new object records: one product and several related marketing campaigns. Copying a single record is sometimes referred to as "shallow" copying, whereas copying a structure of related records is called "deep" copy.
## How to Copy Records To copy a single object record (shallow copy): 1. Navigate to the object record's detail page. This may be in Admin or in a custom tab. 2. Choose **Copy Record** from the action menu. This action is not available if the record's object type is inactive. 3. Vault opens the details page for the new record. Many fields will default to the values on the original record. You can edit these as needed. 4. When finished editing, click **Save**. To copy a hierarchy of object records (deep copy): 1. Perform the steps for a single record copy. 2. If child records exist and hierarchical copy is enabled for the parent object relationship, a pop-up opens. The pop-up displays the objects which will have records copied. 3. Select the **Copy Related Records** checkbox to copy the hierarchy of records identified in the pop-up. 4. RIM Only: Select the **Apply modified values on this record to related records** to choose whether or not to copy all changed field values to all self-related descendant copies. This option is only available when **Copy Record** is performed on self-referencing EDL objects, and is grayed out if **Copy Related Records** is unchecked. 5. Click **Save** to complete the action. 6. Vault validates and copies the highest level record and child records asynchronously. When complete, Vault sends a confirmation email. If there are any validation issues (non-unique name, etc.), the email will include a CSV file with details on the failed copy actions. An Admin must enable hierarchical copy for the parent object record in order for you to perform a hierarchical copy.
## Field Defaulting Vault defaults field values on the new record whenever possible, but fields will be blank or default to a different value in some situations: * A picklist field on the original record that points to a picklist value that is now inactive * An object reference field on the original record that points to an object record that is now inactive. * An object reference field on the original record that points to an object record that you do not have access to through Dynamic Access Control * A system-managed field, like _Created By_ or _Lifecycle_ * A field that requires a unique value * _Status_ field, which defaults to _Active_ for objects that do not use lifecycles and the lifecycle's starting state for those that do ## Related Permissions & Access Control To copy a record, your security profile must grant _Create_ permission on the object. For deep copy, you must have _Create_ permission on all child or grandchild objects for which you're copying records. If you do not have this permission on the child object, the deep copy action cannot copy records for the grandchild object. Additionally, Vault honors [Atomic Security on relationships](/en/lr/47850/#secure_inbound_relationships) and [user actions](/en/lr/47850/#Atomic_Security_Actions) when executing a deep copy. If a user does not have access to a child or grandchild object with _Copy Record_ enabled through Atomic Security, the child and grandchild records are not included in deep copy. See example scenarios [below][0]. If any objects within the hierarchy use Dynamic Access Control, this also affects whether you're able to copy and how deep copying will work. If a user cannot view and create any child or grandchild records under the parent object, the deep copy action cannot copy the child or grandchild records. ### Example Permission Set Scenarios {#example-scenarios} #### Scenario 1 |Object|Create Permission| |--- |--- | |Product|Yes| |Marketing Campaign (Child)|Yes| |Ad Buy (Grandchild)|Yes| In this scenario, when Gladys copies a _Product_ record, she can also copy the related _Marketing Campaign_ and _Ad Buy_ records. #### Scenario 2 |Object|Create Permission| |--- |--- | |Product|Yes| |Marketing Campaign (Child)|Yes| |Ad Buy (Grandchild)|No| In this scenario, Gladys cannot copy any child or grandchild records because she does not have _Create_ permission for the entire hierarchy. #### Scenario 3 |Object|Create Permission| |--- |--- | |Product|Yes| |Marketing Campaign (Child)|No| |Ad Buy (Grandchild)|Yes| In this scenario, Gladys cannot copy any child or grandchild records because she does not have _Create_ permission for the entire hierarchy. #### Scenario 4 |Object|Copy Record Action Security| |--- |--- | |Product|Yes| |Marketing Campaign (Child)|No| |Ad Buy (Grandchild)|No| In this scenario, Gladys can perform a copy on the parent record, but any child and grandchild records are not included with the copied record. ## Audit Trail When you copy a record, the _Event Description_ in the new record's [audit trail](/en/lr/517/) includes the source record's name. [0]: #example-scenarios