Many of my prospects say 'Profile inaccessible' — are they lost?
No — Apr 30 fix (LL#256). Previously, every HTTP 422 response from Unipile / LinkedIn (the surface that includes 'Profile inaccessible' as a customer-facing error) was inline-stamped status='failed' and the prospect was burned with no further retry — even though the LinkedIn 422 surface conflates several semantically-distinct cases, including some that are fully recoverable on a re-resolve:
- Sales Navigator URLs that didn't resolve on attempt N but resolve cleanly on attempt N+1.
- URL canonicalization issues fixed by the LL#253 provider_id-aware fallback.
- Transient resolver issues that clear within minutes.
The platform-wide audit found 21,868 enrollments burned this way.
The fix migrates all 422 dispositions to the LL#253 defer-not-burn template:
- The prospect's status flips to 'pending_resolution' (a new value) instead of terminal 'failed'.
- The engine retries with exponential backoff capped at 5 attempts before promoting to terminal 'failed'.
- The 21,868 historical rows were swept into the same recovery flow with their re-attempts spread over a 24-hour window so the queue doesn't slam LinkedIn rate limits.
What you should do:
- If you see this status on individual prospects: please verify the prospect's LinkedIn URL is current. Regular linkedin.com/in/<handle> URLs resolve most reliably across all Unipile resolver code paths.
- Click Retry on the prospect detail page if you want to force an immediate re-attempt (otherwise the defer flow handles recovery automatically).
- If a prospect repeatedly lands back in 'pending_resolution' after 5 retries, that's a genuinely-terminal restricted profile — the engine will promote it to terminal 'failed' at that point, and you can safely exclude or remove them.
No manual un-burn is needed for the 21,868 historical cohort — the backfill handled it automatically.