Pages and enrichment
Read results and retry failures
Check the result for each prospect rather than treating a batch as a single success or failure. Keep the batch identifier, the run identifier, and the Page URL as separate pieces of evidence.
DocumentationRead the result
For a queued or running PageRun, wait and check progress. For a failed run, read the failure reason before retrying. For a succeeded run, use the returned Page URL to open or share the personalized Page.
Check CRM writeback separately from Page readiness. A Page can be ready while its URL has not reached the CRM. Screenshot and link-preview image stages can also fail independently.
Diagnose by symptom
| Symptom | Next check |
|---|---|
| Profile lookup fails | Correct the intended person’s LinkedIn URL and verify source availability. |
| Required prompt fails | Check the Page owner’s definition, selected sections, and usable prospect input. |
| Blank optional text | Inspect the variable path and actual value; add a deliberate fallback. |
| CRM URL missing | Inspect the separate writeback state and connection. |
Retry only what you intend
First search for the existing result. Creation requests are not an idempotent retry mechanism: submitting again can create another batch and incur new work. Correct the cause and submit only the prospects you deliberately want to regenerate.
Do not repeatedly retry an ambiguous timeout. Check the original run or contact Landit with its identifier and time.