Feed Quick Search from record changes
What It Does
This workflow hands committed person and organization changes to Platform’s Quick Search projection. A coordinator who saves a corrected name needs discovery to eventually reflect it, and archive or deletion must reach the same indexing boundary. CRM transports captured snapshots; Platform owns what a workspace indexes and how the index applies them.
Our reading is that separate handler messages keep search failure from replaying successful compliance or region work. The source record can be correct while its search result is stale. This contract explains transport and recovery evidence without giving CRM a second home for Platform’s indexing policy.
What Starts It
A committed contact or organization transaction leaves a captured change for dispatch. The dispatcher publishes a separate search-handler message carrying the snapshot and stable event identity. This input exists after the source save, so an accepted save and a refreshed search result are separate observations. The workflow starts transport to Platform rather than calculating CRM’s own indexing policy.
The Flow
The diagram shows the sequence and service seams. Each synchronous stage waits for its result, while captured-event, queue and scheduled stages can run after the originating request has returned. The hop descriptions below identify the write and failure boundary, so the last arrow must not be mistaken for one atomic transaction across every participant.
Hop by Hop
1. CRM change-events dispatcher
The dispatcher includes every contact and organization operation and field change in the search handler’s feed. It does not infer which snapshots Platform might want to ignore. Required queue acceptance controls event removal, so publication failure leaves work available for later claim or dispatch.
2. Quick Search indexer handler
The remote handler makes a synchronous indexer call for batches of at most one hundred snapshots and waits for outcomes associated with event identities. Missing configuration, invocation failure or an omitted event outcome counts as failed delivery. Other successful handler messages remain independent of that retry.
3. Platform Quick Search
Platform applies its own projection policy and returns an outcome for each event. Under the cited integration contract, unsupported or deleting workspaces and absent records can succeed without indexing a live subject. A returned per-event failure remains CRM delivery work to retry rather than an instruction to change the source record.
When Something Fails
Hop 1 — CRM change-events dispatcher
The failure boundary is: Reclaim events whose required messages were not accepted. The remaining work or data is: Search can wait behind publication. Dispatcher logs report acceptance and backlog. A later attempt can be required; the scheduling or publication boundary does not establish an immediate user-visible completion.
Hop 2 — Quick Search indexer handler
The failure boundary is: Treat missing outcomes, failed invocation or missing configuration as failed deliveries; retry and dead-letter after five receives. The remaining work or data is: The source record is committed while search can remain stale. Consumer logs and search-handler dead-letter messages identify failed events. This failure is downstream of committed input; operators investigate its own delivery rather than treating the caller’s original save as failed.
Hop 3 — Platform Quick Search
The failure boundary is: Return per-event failure to CRM for retry. The remaining work or data is: A failed event leaves its search projection unresolved. Platform indexer logs and response outcomes provide evidence.
Repeats and Races
Stable event identities accompany each snapshot, allowing Platform to apply its duplicate and stale-snapshot policy. After an ambiguous remote acceptance, CRM may deliver again; this workflow does not assume exactly-once invocation. The transport queue can reorder events even though capture records their sequence, so freshness belongs to the indexer’s handling of those snapshots.
Search has its own handler messages. Retry or dead-letter work for search does not rerun successful compliance or region handlers and cannot roll back the record. Archive changes are forwarded without a CRM-side visibility filter; Platform owns the default search treatment.
What Is Observable
Dispatcher logs report acceptance and backlog. Consumer logs and search-handler dead-letter messages identify failed events. Platform indexer logs and response outcomes provide evidence.
The coordinator continues to read the committed CRM identity while search can lag. Operators correlate event identities, per-event outcomes and handler queue failures. Missing configuration is observable failure rather than a silent skip, and Platform logs provide the next boundary for a message CRM successfully handed off.
Open Design Questions
The existing findings retain limited proof of out-of-order search delivery and complete projection freshness. CRM’s per-event success means Platform accepted or intentionally ignored the event under its contract, not that a particular person saw the new result. Operational evidence for backlog and failed events is needed when investigating stale discovery.