Correspondence Management letter renders blank fields in batch
An insurer uses Correspondence Management (CM) to produce 8,000 welcome letters nightly. The letter template (XDP) has 60 data elements bound to a data dictionary; the batch submits a JSON/XML payload per policyholder via the CM CorrespondenceManagementService. In production, ~3% of letters render with blank address and premium fields, while the same payloads render correctly when tested individually in the CM author UI. The batch runs 4 parallel threads. Logs show WARN: Data element not found: policy.premium for the blank letters only. The data dictionary defines policy.premium as a decimal; some source records send "premium": "" (empty string) and others send "premium": null. The CM service client is a singleton shared across threads.
1. Diagnose the intermittent blank fields and propose the fix at the data and code layers.
Read the worked answer
The warning Data element not found: policy.premium plus 3% blanks indicates a data-type/binding mismatch, not a template defect: the dictionary declares premium as decimal, but source records send empty string or null. When the value cannot be coerced to the declared type, the binding resolves to no value and the field renders blank. Individual UI tests pass because those payloads carry valid decimals.
Data-layer fix: normalize upstream - coerce ""/null to a valid default or omit and handle optionality in the data dictionary (mark optional, provide default), and validate payloads against the dictionary schema before submission.
Code-layer fix: the shared singleton CorrespondenceManagementService client across 4 threads is a concurrency risk; use a client per worker or a documented thread-safe pool, and isolate per-record state. Add schema validation and fail/report records that don't conform rather than silently emitting blank letters. Re-run a 500-record canary including empty/null cases.
2. The business wants 'no blank letters ever.' Describe the guardrails you would add and how you would verify them.
Read the worked answer
Guardrails:
- Pre-submission validation against the data dictionary schema; reject or quarantine non-conforming records with a reason code.
- Mandatory-field enforcement in the dictionary (address, premium) with explicit defaults where business allows.
- Post-render assertion: after generation, verify required fields are non-empty (parse the PDF text or check the CM result metadata) before release; route failures to an exception queue.
- Concurrency correctness: per-worker client, no shared mutable state.
Verification: build a test corpus covering valid, empty-string, null, and out-of-range values; run a canary batch and assert 0 blank required fields; add dashboards for quarantine rate and render-assertion failures. 'No blanks ever' is achieved by rejecting bad input and asserting output, not by hoping the template handles it.