Forty DocGen packages — and nobody knows which are live

Of the 28 DocGen checks, five report configurations that break or strand document generation outright: a package missing its templates or delivery; a template row whose backing file is gone; a relationship pointing at an object the scan did not find; a starting object that no longer exists; and duplicate packages where no copy actually works. Each names the package, so the fix is a worklist item rather than an archaeology project.

Behind them, the hygiene tier: packages behind the version model, licenses expired or expiring, test and sample templates on active packages, per-variant package families that conditional documents would consolidate, cloned version chains, naming drift, orphaned child records, and delivery options composed inline instead of from templates. And the housekeeping tier — low severity, honest about it — from missing help text to output stored as classic Attachments.

The DocGen scan is a per-org opt-in with a consent card that states its whole appetite: package, template, relationship and delivery names plus derived flags. Never template contents, never SOQL text, never a generated document. Until you opt in, the report says “DocGen assessment not enabled — its checks were skipped” rather than pretending the module ran clean.

DocGen fixes are guided — package configuration is Nintex-owned, and Horus Eye does not write into it. What you get is the worklist with evidence; what Kemisoft’s Nintex practice brings is a Premier Partner’s hands to clear it — consolidation, conditional-document design, and the DocGen Health Assessment engagement this module was built to feed.