Cross-Instance Cloning
Cross-Instance Cloning is in beta. It may not be turned on for your account yet. To request access, contact Paminga Support.
If your organization runs more than one Paminga instance (a region per instance, a brand per instance, or a sandbox beside production), Cross-Instance Cloning lets you build an asset once and clone it into another instance, instead of rebuilding it by hand.
A clone is more than a copy. Each instance has its own custom fields, drop-down options, users, and lists, so a raw copy would point at things that don't exist on the other side. Cross-Instance Cloning translates those references into their equivalents in the target instance, and brings along the segments, lists, forms, and emails the asset depends on.
The instance you clone from is the source; the one you clone into is the target.
Before You Clone: Map Your Fields and Users
Paminga can only translate a reference it knows the answer to, so the first step is telling it how your instances correspond. That happens on the Cross-Instance Cloning page in Account Settings, from the source instance.
Choose the Target Instance at the top of the page. The list shows the other instances in your organization. If your instance isn't part of a multi-instance organization, the page says so and there's nothing to map.
Custom Fields
The Contact, Account, and Opportunity tabs list every custom field in the source instance. For each one, choose its equivalent from the Target Field column, or choose Do Not Map. Each choice saves immediately.
The Where Used column (Contact and Account tabs) shows where each field is used in the source instance, which helps when you're deciding whether a field matters.
If the target doesn't have an equivalent yet, click + on the row to create one there. The Create Field in Target Instance drawer creates a field of the same type, with the name you choose. For a drop-down field, give the new drop-down a name; its options are copied from the source drop-down. The new field is mapped automatically. Lookup and relationship fields can't be created this way and need to be set up in the target first.
Before anything can be cloned to a target, every Contact, Account, and Opportunity custom field in the source must be mapped to a field in that target, not only the fields the asset uses. A field set to Do Not Map counts as unmapped. This is what guarantees that no clone ever carries a reference into the target that points nowhere.
Mapped drop-down fields need matching options too. Options are matched by value, so the target's drop-down must contain every value the source's does.
Users
The User tab maps each active user in the source to a user in the target. User mappings matter for Send Notification actions, which address people by their account: every notification recipient needs a mapped counterpart before the asset can be cloned.
Click + to create a matching user in the target. The new user is linked to the source user, isn't sent a welcome email, and is created without roles, so give them access in the target's Users settings.
Clone an Asset
You can clone these from their tables in the source instance:
- Emails
- Forms (built with the Form Builder)
- Landing Pages
- CTAs
- Workflows, including drip workflows
Click the Clone this … to a target instance row action, then choose the target instance.
Paminga checks the target before it lets you clone. If something needs attention, the dialog tells you what and how to fix it, such as:
- Custom fields that still need mapping, with an Open mapping page link straight to the right tab
- Drop-down values that need adding to a field in the target
- Notification recipients with no mapped user
- Google Ads conversions recorded through a connection the target doesn't have. Connect the target to the same Google Ads account(s) under Settings → Integrations
- Lead-scoring rulesets that need exactly one ruleset with the same name in the target
- Segments with the same name in the target but different conditions. Rename one, make them match, or delete the target's version
When everything checks out, the dialog shows Ready to clone with a summary of what comes along: the asset itself, plus its segments, marketing lists, subscription lists, embedded forms, and emails referenced by actions, each counted as existing (already in the target and reused) or new (created by the clone). Adjust the Name in field if you want a different name in the target, then click Clone.
What Gets Cloned, and How
Dependencies
- Segments: a segment the asset uses (including the Personas behind dynamic content) is reused if the target has one with the same name and identical conditions; otherwise a new one is created.
- Marketing and subscription lists: reused if the target has a list with the same name; otherwise created empty. Contacts are never copied between instances.
- Forms: forms embedded in a page, or named in a "submitted this form" condition, are reused by name or cloned.
- Emails: emails sent by an action are reused by name or cloned.
- Workflows: a workflow named in an add-to or remove-from workflow action is reused by name or cloned too. Cloned workflows keep every node, with branches and go-to steps rewired.
- Actions: send email, add to and remove from lists, add to and remove from workflows, send notification, Google Ads conversions, adjust lead score, and move to node are carried across and pointed at their target-side equivalents.
Remapped References
| Reference | How it's translated |
|---|---|
| Contact and account custom fields in segment conditions | To the mapped target field |
| Personalization tokens for contact and account custom fields | To the mapped target field. Standard-field tokens carry over as they are |
| Liquid references to contact and account fields | To the mapped target field |
| Drop-down option selections in conditions | To the target option with the same value |
| Notification recipients | To the mapped target user |
| Google Ads conversion actions | To the target's connection for the same Google Ads account |
| Lead-score adjustments | To the target ruleset with the same name |
How Clones Arrive
- Emails are published in the target, unless the target uses Approvals, in which case they arrive as drafts.
- Forms, landing pages, and CTAs arrive as drafts.
- Workflows arrive as drafts, with run and launch dates cleared.
- Landing pages arrive without a domain or path. Choose one in the target before publishing.
- Every clone uses the target's default Brand Kit, so the target needs one.
- Clones land at the top level of the target's Finder. Move them where you want them afterwards.
- Tags on the asset are recreated in the target by name.
Limits
- Not every token is remapped. Folder tokens and event tokens aren't translated and keep pointing at the source instance. Check any asset that uses them after cloning.
- Some things are skipped, with a warning. Conditional actions, workflow goals, action types without cross-instance support, and segment conditions based on events or workflow activity aren't translated. Paminga shows a warning for each one after the clone.
- Names must be unique. The asset's name must not already exist in the target, or the clone fails. Change the Name in field and try again.
- Classic emails and classic forms, Action Sets, and whole folders can't be cloned across instances.
If a clone fails partway, Paminga removes whatever it created in the target, so you're never left with a half-cloned asset.
Who Can Use It
Cross-Instance Cloning is available on accounts where the beta is turned on, and only between instances that belong to the same organization.
You don't need your own login in the target instance. The clone is created on behalf of a user there: you, if you have an account in the target; otherwise a user with the same first and last name; otherwise the target's first active user.
