Horus Eye · Nintex DocGen
Forty DocGen packages — and nobody knows which are live
Every long-running Nintex DocGen install — many dating back to when the product was called Drawloop — accumulates the same sediment: packages named v1, v2, final and FINAL2; documents that fail because a template file quietly disappeared; delivery emails with no subject; test packages generating in production; a license expiry nobody is watching. Horus Eye’s DocGen module reads the configuration — names and flags only, by explicit opt-in — and turns the sediment into a worklist.
The five findings that stop documents generating
High severityAmong the 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.
Read by consent, and only the shape
The opt-inThe 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 package missing templates or delivery
- What Horus Eye detected
- A DocGen package appears configured with no attached templates and/or no delivery option — a run would have nothing to generate or nowhere to send it.
- Evidence
- Package, template and delivery-option rows and their derived flags; names only.
- Why it matters
- Users hit generation failures that look intermittent but are structural; support burns hours re-diagnosing a package that cannot work.
- Recommendation
- Complete the package or retire it; where several near-copies exist, keep the working copy and consolidate the variants — Horus’s plan names each package involved.
- Confidence
- High — configuration rows read directly; runtime generation not executed
A report card, then a worklist
Understand · Decide · Fix & validate · ReportThe assessment grades the estate area by area — Requires Attention, Improvement Opportunity, Good Standing (examined and clean, not assumed), and Not assessed, said out loud. Each finding becomes one question with numbered options and the usual answer marked; recording an answer writes nothing to Salesforce. The scorecard areas, explained →
Guided clearing, and whose hands
The honest three-way splitYou decide
Which package is the keeper, what the help text should say, which single word names a delivery, when to move storage to Files. Decisions only the organization can make — recorded, never defaulted.
Applied after your yes
Quick wins: one allowlisted field on an existing DocGen record — fill an empty subject, write help text, retire a test package (set inactive, nothing deleted) — previewed with its before-value, confirmed by you, read back, and reversible. A fix counts as verified only when its rule goes silent on the next scan.
The DocGen admin’s hands
The structural work: re-attaching template files, repointing relationships, splitting SOQL, consolidating clones — with step-by-step guidance, and Kemisoft’s Nintex practice as those hands when you want a Premier Partner on it.
Go deeper: the common issues and their fixes · the admin’s monthly and quarterly routine · the assessment report, page by page · the Horus Eye FAQ · Nintex’s own DocGen documentation. Coming from Conga, or weighing Conga alternatives? The Conga → DocGen migration path is its own story.
Frequently asked questions
Straight answersWhat does the DocGen scan read?
Names and derived flags of packages, templates, relationships and delivery options — by explicit opt-in. Never template contents, SOQL text, or generated documents.
Why is versioning by cloning a problem?
Because v1/v2/final/FINAL2 are four packages Salesforce treats as unrelated: fixes land in one, users generate from another, and nobody can retire any of them safely. Conditional documents inside one package are the consolidation path.
Can Horus Eye fix DocGen packages?
Three-way split: quick wins are applied after your approval (one allowlisted field, previewed, reversible); decisions stay yours; structural work belongs to the DocGen admin — with Kemisoft’s Nintex practice as the hands when you want them.
Live webinar · Kemisoft & Nintex · Tuesday, October 27, 2026
Beyond basic document generation — Nintex DocGen, real-world use cases & Salesforce Org Intelligence
A free 30-minute session (25 minutes + 5 min Q&A): a practical introduction to Nintex DocGen for Salesforce, how it compares with alternatives such as Conga, two real-world use cases, and a Horus Eye demonstration. Can’t make the time? Register anyway and we’ll send the recording.
Protected AI — the Trust Layer
Every AI read in Horus Eye is metadata-first: built from an allowlist, sanitized by pattern, made through one audited gateway and checked by an output firewall on the way back — and AI is off by default, per org. Every request carries an audit id and an AI Data Scope manifest you can open.
Get your DocGen score now
Opt in, scan, and get the graded DocGen picture — broken, duplicated, expiring and test residue, each named.
Try Horus Eye Free Analyze Your Salesforce Org All Horus Eye pagesFree start · 250 credits for 60 days · no card required · scans are free