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.
