The Clone action lets you create another Landing Page by duplicating an existing Landing Page record.
This is useful when a new campaign, audience, offer, or test variation should begin with an existing Landing Page rather than with a new system Template.
After cloning, AIUNIFY Funnels returns you to the Landing Page listing.
The clone controller creates the copied Landing Page with a Name beginning with:
Copy
followed by the original Landing Page Name.
For example, a source Landing Page named:
Spring Campaign
is initially cloned as:
Copy Spring Campaign
Each Landing Page receives its own generated code when a new Landing Page model record is created.
The clone operation creates a new record, so the cloned Landing Page receives its own Landing Page code rather than using the original Landing Page's code as its identity.
The clone operation explicitly creates a new generated subdomain using a new random string combined with the application's configured domain.
This prevents the clone from simply reusing the original Landing Page's generated subdomain.
The clone controller explicitly sets the cloned record's custom_domain value to null.
A custom domain belonging to the original Landing Page should therefore not be assumed to carry over as a usable custom-domain value for the clone.
Important: Review the cloned Landing Page's Domain Settings before distributing its URL. The clone process clears the custom-domain value, while other replicated Landing Page attributes can remain copied from the source record.
Because the clone operation duplicates the Landing Page record and then specifically replaces the generated subdomain and clears the custom-domain value, you should open the clone's Landing Page Settings and confirm that its selected domain mode and displayed Domain value are valid for the new campaign.
Do not assume that the clone is ready for a custom domain merely because the source Landing Page used one.
The clone operation uses the application's record replication function before applying the clone-specific Name, generated subdomain, and cleared custom-domain values.
As a result, the cloned record can begin with saved Landing Page attributes from the source, including its page-content and configuration fields unless the clone process specifically replaces them.
This is why cloning is useful for creating a variation of an existing campaign.
The clone process does not explicitly reset the Landing Page's is_publish value in the clone controller.
Because the record is replicated, the source Landing Page's saved publish state can therefore be carried into the clone.
Important: Immediately verify the clone's Publish status before editing, testing, or distributing the new Landing Page. Do not assume every clone begins as unpublished.
The clone operation duplicates the Landing Page record itself.
Captured form submissions are separate FormData records related to their source Landing Page.
The clone controller does not duplicate those related Lead records as part of the Landing Page replication process.
The cloned Landing Page therefore starts as a new Landing Page record rather than as a duplicate history of the source campaign's captured Leads.
Clone creates another record; it does not replace or delete the original Landing Page.
After the operation, use My Landing Pages to distinguish the source Landing Page from the newly created Copy ... record.
After a successful clone operation, the controller returns to the Landing Page listing with a success message based on:
You copy the landing page [name] successfully
The original Landing Page Name is inserted into that success message.
Clone is usually the more efficient starting point when most of the existing Landing Page should remain the same.
A new Template may be a better starting point when the new campaign requires a substantially different structure.
Operating principle: Treat a clone as a copied working configuration that must be reviewed, not as a guaranteed unpublished blank variation.