Work item QA compiles related work item timelines and ComplyAdvantage screening resources before calling the evaluator. Ingestion also queues resource gathering. The ComplyAdvantage connection must be active in the organization’s region.

Discovery reads explicit search/entity links from task events, descriptions, and linked ticket transcripts. For screening, AML, KYC, or compliance-team tasks it also resolves Intercom contact external_id values and queries ComplyAdvantage client_ref history. Customer matches are labeled as related history; they do not prove task use or analyst attribution. Customer references are cached for seven days in client_integration_profiles.source_external_id, with freshness measured by last_synced_at. The profile’s external_id remains the Intercom contact ID. A missing or stale reference is fetched from Intercom and written back to the same client/connection profile, including during backfill. Screening searches are cached for fifteen minutes when retrieval was complete.

Provider requests are GET-only. Decisions, comments, and submitted search terms pass through the organization’s existing PII redaction rules before persistence. Redaction failures store an unavailable search record with no provider content. No configured redaction rules also fails closed for narrative content.

Deploy the Rails migration adding client_integration_profiles.source_external_id before the API2 release. The separate API2 identity cache is retired by a follow-up Drizzle migration; the original migration remains unchanged.

Backfill

In the staff maintenance task UI, run ComplyAdvantage work item resource backfill (work-item-resource-backfill). Provide the organization slug (nala), UUID, or Rails ID. The default dry run counts eligible non-deleted work item rows without provider calls or writes; it does not estimate how many screenings will be found.

The equivalent staff API request is POST /admin/maintenance/tasks/work-item-resource-backfill/run:

{
  "args": {
    "organization_id": "nala",
    "dry_run": false,
    "max_items": 10000,
    "force_refresh": false
  }
}

Read progress through GET /admin/maintenance/runs/{jobId} using the returned job_id. Progress includes processed counts, coverage statuses, failed work item IDs (up to 100), and last_work_item_id. Set after_id to that cursor to continue a capped or interrupted run. A resumed run skips earlier failed rows; rerun from the beginning after fixing an integration failure to retry those rows. Rerunning is idempotent for resource identities and associations; successful cached searches are reused. force_refresh bypasses the screening search cache.

The backfill does not create provider searches, change screening decisions, rerun evaluations, or change existing QA scores. New evaluations gather required evidence and save an immutable prompt packet containing the evidence used. Retries reuse that packet; a deliberate new evaluation receives a new packet.

Coverage and historical limitations

Linked activity shows each screening as a compact thread item. Clicking opens the search in ComplyAdvantage; hovering previews the search term, decision, risk, result count, creator, assignee, association origin, and retrieval details. Lookup-status cards are not thread items. Related work item context preserves each event’s original task and actor. Search creator, assignee, and decision-maker are separate concepts; Classic API data does not provide a full analyst audit trail.

Gathering limits are explicit: 50 linked conversations, 10 contact identity lookups, 5 customer identities, 500 history records per customer, 10 selected history searches per customer, and 25 resources per connection per task. Entity retrieval is capped at 500 hits and comments at 1000. Explicit links are prioritized; older referenced searches remain eligible. History searches created after task completion are excluded. Missing or truncated evidence is reported rather than interpreted as employee failure.

Evaluation context includes up to 10 related work items, an 80,000-character related-event budget, and a 120,000-character screening-data budget. Full redacted screening records remain stored when evaluation context is shortened. Current provider state cannot reconstruct what was visible at the historical task completion time.

api2.screening_searches stores one current, redacted record per connection/search reference. conversation_thread_items.screening_search_id links it to the canonical thread. Discovery provenance is stored on that item, including the originating work item, so merges combine associations and re-discovery can remove stale associations without unlinking another task’s evidence. A shared provider search never merges two threads. Organization and agent visibility are enforced when rendering resources.

Screening-search rollout

Apply Rails migrations 20260902173104 and 20260902173110 first. Drizzle migration 0329_screening_searches verifies the concurrent thread index is valid, creates the search table, and copies existing redacted search data and links. It intentionally leaves the four legacy resource tables available while old API and worker tasks drain. No provider backfill is needed for this migration.

After all Rails and API2 API/worker services use the new revision, run in each region:

node scripts/retire-work-item-resource-tables.mjs --old-workers-drained

The command takes a transaction lock, copies any late legacy writes, verifies search/link coverage and redaction, and drops work_item_resources, work_item_resource_snapshots, work_item_resource_links, and work_item_resource_gatherings. It is safe to rerun. Do not run it while an older worker can still write to those tables. Existing work_item_evaluation_contexts.prompt values remain intact, so past QA evaluations stay reproducible.

Gathering outcomes live in job progress and the compiled QA context. no_searches means a completed lookup found no matching search; scorecard instructions can treat that absence as screening not done. unavailable and partial are inconclusive. A search with zero hits is a performed search.