Locate people and organizations
Purpose
Staff need to locate a person or organization before they can inspect or use its record. This capability distinguishes name discovery, current-affiliate discovery, and full record reading, so a short label does not become the only account of identity or membership. It also provides controlled reads for integrations with narrower information needs.
How It Works
Lists return pages ordered by record number and supply an opaque continuation cursor. Name search examines the display and sort names; it is not an e-mail or record-number lookup. A direct read returns the aggregate and attribution, or a selected projection with the identity needed to recognize it.
Current organization filtering considers every affiliation effective on the workspace day. Descendant discovery traverses the organization hierarchy and returns each qualifying contact once, including secondary affiliates. This answers a different question from Quick Search's primary-organization subtitle. Quick Search reacts to committed change events, so a direct read can show a saved change before search catches up.
Access is checked at the application, workspace, and record permission boundaries. Knowing an identity does not grant reach. After authorization, a merged-away record can identify its survivor, while a never-existing identity is missing. Record reads also supply image and document display links through Platform files. The proposed metadata-card presentation remains distinguishable from service-read evidence.
Example
Vic is primarily affiliated with his school and also currently serves Harbor West Chapter. A coordinator filters contacts by the chapter and finds Vic; a national body's descendant listing finds him once as well. Quick Search still labels him with the school. Opening his record explains both affiliations, so the different subtitle does not imply he is absent from the chapter.
The coordinator also inspects what each discovery surface proves. A chapter list answers about people with effective ties today and includes Vic only once, even if more than one tie qualifies. The organization's dated people view can instead show separate relationship rows and past service. An integration retrieving selected fields checks the returned identity with its requested values; projecting a smaller payload does not grant access to another workspace. A refused application or record permission stops the read. If Quick Search lags a save, the coordinator opens the record directly rather than treating an older subtitle as evidence that the save failed.
Why It Works This Way
Our reading is that bounded pages and opaque cursors keep ordinary discovery predictable without exposing an implementation-specific paging key. Literal search punctuation prevents a name from becoming an unintended wildcard expression. Distinct people rather than affiliation rows answer the current-membership question without double-counting a person with several qualifying ties.
Application access and workspace reach prevent record permission keys from crossing a customer's boundary. Projection limits a caller's requested payload but does not replace authorization. A survivor response distinguishes a changed identity from missing data. Event-fed search explains why successful persistence and search freshness need separate verification. The architecture's desired freshness discipline does not establish a measured search delay at this milestone.
Relationships
Contact Records and Organization Records establish the identities returned here. Affiliations and Roles supplies current membership and workspace-date semantics, while archive controls default availability. Platform owns query execution and Quick Search infrastructure, reached through their contracts and committed change events. Data Quality supplies merge survivors; history has separate permission and reading behavior.