Index CRM record changes into Quick Search
What It Does
CRM submits a batch of at most one hundred record-change events to the search indexer.
The Flow
Receive the CRM batch and return a result for each event. Skip scopes that are absent, unready for indexing or deleting, and ignore changes proven unrelated to configured projection fields. Claim versions before reading projections and write each record’s target-generation document or deletion state through the query layer. Refresh contacts affected by organization changes, using a related rebuild when the fanout exceeds two hundred.
When Something Fails
The submitting service retries missing or failed results under its change-delivery policy. Search remains behind committed CRM changes until indexing or repair succeeds. Skipped events are acknowledged rather than treated as indexing failure. No document update is attempted for those skipped scopes. Provider failures report affected workspace events as failed. Claimed versions can precede provider contents until retry or reconciliation repairs the write. A failed job start leaves a pending rebuild for recovery. Related display values can remain stale until that work succeeds.
Idempotency and Concurrency
Distinct records are projected under newly claimed versions. Provider ordering rejects older writes, while duplicate events can cause newer claims and repeated projection reads. Five indexer invocations are reserved; CRM owns delivery buffering and retries when the indexing function is throttled or fails.