Search Index
What It Is
The search index is a prepared copy of information used to find records quickly. Staff type a name, e-mail address or part of a phone number and receive recognizable contact or organization hits. Rhythm maintains selected values with an external search provider so that every keystroke does not require another ordinary record query.
Documents carry record identity, display information and indexed field values. The workspace’s configuration chooses eligible fields and their ranking tiers. Phone values can include normalized alternatives so punctuation does not prevent a digits-only search. This information remains derived: the application’s record is still the authoritative source.
A shared provider index serves workspaces through restricted credentials. The credential embeds the workspace, live-document and permitted-type boundaries. The browser sends direct search requests with that credential and adds its own narrowing choices. The stored index and the access credential therefore answer different product questions: what has been prepared for discovery, and what this person is allowed to search now.
What It Is Not
The index is not an editable contact or organization store. Opening a hit reads the actual record through its owning application. It is also narrower than an Explorer query, because it holds configured search fields for declared record types rather than every queryable value. The console’s separate Search page currently uses sample records and should not be treated as this live search surface. Duplicate detection belongs to separate CRM work.
How It Is Used
Staff use the header search dialog for repeated short lookups. Ordinary discovery excludes records marked inactive or archived unless the person asks to include them. That choice resets on opening the dialog again. Search access currently uses contact-read authority for organization hits as well; the conflict with a later organization-access ruling remains a product question.
Administrators maintain field configuration through the API. Rhythm processes source changes, refreshes related contact documents and rebuilds generations when configuration changes. A failing provider write for one workspace does not invalidate other workspaces’ events. Scheduled repair supplies recovery when events or rebuild submission are missed. Missing provider configuration makes the surface unavailable.
Its Facets
Record type. The registry currently covers contacts and organizations, with a dataset and access requirement for each.
Field list. Eligible values and ranking tiers define the customer’s useful search vocabulary. Default fields apply before explicit configuration.
Search credential. The key lasts fifteen minutes, so access changes can remain stale until renewal. Its embedded boundaries cannot be widened by a browser request.
Discoverability. Status and archive markers let the dialog narrow ordinary searches while permitting an explicit inactive-record search.
Generation and rebuild. Replacement work preserves the old generation until validation permits activation.
Repair passes. Owed targets, nightly reconciliation and retained deletion counters address different maintenance failures.
Degraded field. Retired metadata stops contributing to index content but remains visible in configuration so the administrator can repair it.
How It Relates
Datasets supply projections and CRM supplies record-change events. Metadata changes can retire configured fields. Workspace lifecycle creates and removes resources. Search hits provide a route back to authoritative records rather than transferring their ownership to the provider.
What It Could Become
The product should resolve organization-search authority and decide when configuration deserves a console screen. More record types could extend discovery after their ownership and access are specified. The pinned record states that production lacks the provider; current deployment availability should be checked separately from this specification.