It starts innocently: the proposal package needs a change, changing it live feels risky, so someone clones it. Proposal v2. Then the region variant. Then final, then FINAL2. Two years later there are forty packages, documents occasionally generate from the wrong one, and nobody can retire anything because nobody is sure which are live.
Why cloning multiplies instead of versioning
Salesforce treats each clone as an unrelated package: fixes land in one and not its siblings, users bookmark the one they used last, and delivery options drift apart silently. The name chain records the intent to version; the platform records only parallel packages.
The consolidation pattern
Conditional documents inside one package: one package per business purpose, with rules deciding which template variant applies — region, language, format. The family collapses to one maintained object, and retirement of the residue becomes possible because generation provably flows through the keeper.
Finding the families is the tedious part in a large install — Horus Eye’s DocGen module (an explicit opt-in that reads names and flags only, never template contents) flags cloned version chains, near-duplicates and per-variant families, and names each package. The consolidation itself is Nintex design work — Kemisoft’s document practice has been doing it since before it was fashionable.
How to spot clone-sprawl in an afternoon
Open the DocGen package list and sort by name: clones almost always announce themselves with suffixes — Copy of, v2, FINAL, a person’s initials, a fiscal year. For each family of similarly-named packages, answer three questions. When did each last run? (A package with no deliveries in twelve months is a candidate for retirement, not maintenance.) Which delivery option and template does each reference? (Two packages pointing at the same template with the same options are duplicates in fact, whatever their names say.) And who asked for the copy? The answer usually locates the one change that justified the clone — a change that belongs in the original as a documented revision.
What to do with the copies
Treat the family as one decision, not many: pick the survivor, fold the one real difference back into it, and retire the rest in two steps — rename with a clear RETIRED- prefix first, then remove after a full business cycle proves nothing called them. Button and quick-action references hide in page layouts and utility bars, so sweep those before the final removal. The discipline that prevents the next sprawl is cheap: one package per document purpose, changes made as revisions with a note, and copies reserved for genuine experiments with an expiry date.
The bottom line
Clone-sprawl is never one person’s fault and always one afternoon’s diagnosis. Run the sort, ask the three questions, pick the survivors — and put the one-package-per-purpose rule in writing so the next urgent Friday produces a revision instead of a copy.
