A campaign is a configuration graph

The visible campaign record is only the root. Its behaviour is usually spread across questions, answer options, reminder rules, appointment settings, style, FAQ, messaging assignments, and templates.

Copying the root creates a shell. It does not create a runnable campaign.

Rebuild ownership and links

A deep clone creates a new draft campaign and then recreates campaign-owned records. The difficult work is rebuilding references: copied options point to copied questions, reminder rules point to the new campaign, and each related module gets the new relationship rather than a hidden link back to the source.

source campaign graph
→ create draft root
→ copy owned modules
→ rebuild links to new records
→ validate before publish

Operational data must remain outside the clone. Leads, conversation history, message logs, appointments, active reminders, execution logs, and published runtime snapshots belong to the old campaign's history, not the new draft.

Dry run before writing

I like a preflight step that checks the source exists, the new campaign key is available, required modules are present, and supposedly unique records are not ambiguous. This is not glamorous, but it turns a large write operation into something that can fail safely before it creates partial configuration.

What I learned

Configuration cloning is graph copying. The key design decision is not “copy everything”; it is explicitly defining what is owned, what is shared, what is historical, and how every new relationship is rebuilt.

What should happen next

I want a clone manifest that records each source-to-target mapping and supports clear cleanup if a later stage cannot be completed.