CloneSpec Structure

A CloneSpec document contains the following key elements:

• ObjectName : The name of the object participating in the clone operation.
• OverrideFields : A collection of field-value pairs that define which field values to override in the cloned record. You can use direct values or template expressions.
• ChildObjectsToClone : In a deep clone scenario, this section lists the child objects to include in the cloning operation along with their parent field references.

{
  "ObjectName": "PriceList",
  "OverrideFields": {
    "Name": "{\"Template\":\"Clone-{0}\",\"ObjectFields\":[\"Name\"]}"
  },
  "ChildObjectsToClone": [
    {
      "ObjectName": "PriceListItem",
      "ParentFieldName": "PriceList",
      "Label": "Price List Items",
      "GroupName": "Items"
    }
  ]
}
      

Storage Mechanism

Previously, CloneSpecs were stored through the platform's configuration-management API as escaped JSON strings within a configuration entry. The new CloneSpec Management API provides a structured interface that eliminates the need to handle escaped JSON manually.

The legacy configuration entry format required:

{
  "Category": "CloneSpec",
  "Name": "<ObjectName>[-<scenario>]",
  "Value": "<serialized clonespec json-document>"
}
      

With the new CRUD API, you interact with CloneSpec objects directly using a clean JSON structure.

CloneSpec Scenarios

You can define multiple CloneSpecs for the same object to support different cloning scenarios. To create a scenario-specific CloneSpec, append the scenario name to the object name when you specify the <codeph>specName</codeph> parameter.

For example, you might define separate CloneSpecs for:

• Default cloning behavior (example, <codeph>PriceList</codeph>)
• A specific workflow scenario (e.g., <codeph>PriceList-renewal</codeph>)

At runtime, the system uses the scenario-specific CloneSpec if available; otherwise, it falls back to the default CloneSpec for the object.