Clone to another project is a function that allows you to “copy paste” your work from one project to another. You can find it in almost all Exponea functions and modules (reports, scenarios, predictions, etc.).
Be careful when cloning, make sure to check you are cloning correct items and to correct projects/accounts, it is irreversible and may cause mess if done incorrectly.
Make sure to not close the window during the cloning process, as this will abort the progress.
To clone an item, click on it and select ‘Clone to another project’
You will be able to choose multiple Accounts and Projects you wish to clone the item to.
Afterward, you will be prompted to check the Cloning settings, to add the item to Initiative, set the Suffix, and Use data mapping. In this part of the process, you can use the ‘Linked settings’ (by clicking the link icon). This allows you to jointly apply changes in Initiatives and suffixes to all the projects where the item is being cloned.
- Initiatives - You can choose to add the items you are cloning to an initiative in the target project. If using ‘Linked settings’, Exponea will try to find the initiative name picked for one project in all others automatically. You can also choose to create a new initiative if the initiative you seek is not present in the target project. The initiatives will be created right away and will not wait until cloning. In case you cannot create the initiative, e.g. due to insufficient rights, you will get a notice.
After you click ‘Next’ Exponea makes sure to check for dependencies. This happens in 2 stages, after which you will be able to choose how you want to proceed.
1. Finding dependencies
Most of the items use some other items inside them. E.g email campaign may use jinja to get an aggregate value or audience filter using segmentation. All such dependencies are identified (as well as the dependencies of the dependencies) to find the full set of items that need to be cloned in order for the original item to be fully functional after cloning. This includes not only finding the dependencies but also updating the references such as aggregate ID in jinja while cloning.
2. Finding duplicates
All recognized dependencies are compared with already existing items in the target project.
Items are considered duplicates if some item from the target project and item from the dependency list fulfill all of the below criteria:
- The target item was created by cloning from the source item or the other way round (items keep a reference to source items they were cloned from), or share the same internal id (if the target project is the same as the source project).
- Items share the same type e.g. scenario, aggregate
- Items share the same name, including the suffix from clone settings
- Target project item is in the same initiative as the chosen initiative from clone settings or no initiatives are set.
Individually created items will be never matched as cloning duplicates.
Individually created items (without use of cloning) will be never recognized as cloning duplicates.
Even if they have the same type, name and initiative.
In case duplicates are found , you can choose if you wish to duplicate, replace or use existing target item:
Duplicate - creates a new ‘copy’ of the item in the target project, both pre-existing and new definition is kept, all dependencies are updated to use the newly created ‘copy’
Replace - the existing definition is replaced by the new one, and all dependencies are updated to use the existing item
Use Existing - the existing item is kept unchanged and the new one is not cloned, all dependencies are updated to use the existing item
In rare cases, if an error occurred when reviewing dependencies, you will also be able to see in which projects the error happened. E.g. if data mapping causes multiple events to be mapped to the same event, then it will give an error in dependencies review.
At the end of the process, you will be able to see the results of the cloning, and if there were any errors, you will see them as well. E.g. if you don’t have the required permissions in a certain project and thus the cloning there failed.
For cloned scenario email nodes, email campaigns, or email templates, the email provider is replaced by the default provider configured in the target project. In case the default provider is not configured, the email provider is left unset.
All campaigns are reset to status ‘Draft’ upon cloning. For example, cloning a running campaign will not start the campaign in the target project.
Authentication integrations (in webhooks) and Ads integrations (in ads audiences) used in scenarios are removed and must be added manually after cloning.
Different projects have different names for their events or customer properties, which would normally make cloning between projects complicated. This problem is solved by the function
Use data mapping.
After ticking the box, upon cloning, this function automatically modifies all cloned items based on the mapping and translates your events´ names and attributes, customer properties, and catalogs names used in the items from the mapped data in the source project into mapped data in target projects.
This process helps you eliminate manual changes needed after cloning items between projects. Learn more about Data mapping. It is turned on by default, but you can switch it off to prevent modification of your original definitions.
It is worth noting that customer properties or event attributes mapping was not implemented for all occurrences. Only some entities are searched for data mapping during cloning. These would include, e.g. all Jinja, customer filters, reports, and others for customer properties; or event filters, campaign audiences, aggregates, and others for events.
If you are unable to clone your event (Exponea saying that “Multiple custom events mapped to the same original event”), adjust your data mapping to make sure that different events do not have the same event attributes.
Updated about a month ago