The accession page that must not guess its record
A museum catalog returns several photographs with similar titles, including multiple versions of a restoration project. A visitor chooses one result and opens its detail page. If the application runs the title search again and takes the first ranked hit, it could show a different photograph after an index update or ranking change. Azure AI Search has a direct document lookup operation for precisely this handoff: retrieve one indexed document by its key. The key must come from the selected result or another trusted mapping, not from a guessed title string. This is an illustrative application design, not a report of a live museum database or a tested endpoint.
Separate ranked discovery from direct document retrieval
Full-text, vector, and hybrid searches evaluate a query against an index and return candidate records, often ordered by relevance. A Get Document request takes a known document identifier and retrieves that one document without an index search or scan. Microsoft explicitly describes document lookup as a way to populate a details page after a user chooses an item in search results. This makes it appropriate for a stable result-to-detail handoff, not a replacement for finding unknown records. A lookup does not try fuzzy spelling, keyword expansion, or semantic ranking. If the application lacks the correct key, it must establish the identity from a valid source rather than inventing it from the title.
Identify the actual key field in the index schema
Each Azure AI Search index defines exactly one top-level document key field of type Edm.String. The key identifies search documents uniquely within that index and must be populated from unique source values or an indexing strategy that creates such values. A public accession number and an internal search-document key are not automatically the same thing. Some pipelines split a single archival source into multiple chunks; each chunk then needs its own unique document key, with a separate parent identifier if desired. Inspect the index schema and keep a clear source-to-search-key mapping. Do not silently substitute a display title or an unrelated catalog UUID for the field Azure AI Search treats as its key.
Capture and preserve the selected result identity
When the user clicks a search hit, carry forward the exact key returned in its result, along with the index or collection context that the application controls. Treat the key as data: encode it correctly when constructing an API request, but do not transform its case or trim meaningful characters. Microsoft documents that key comparisons are case-sensitive for indexing and lookup. If the interface shows an accession code that differs from the search key, display both concepts correctly in logs and diagnostics. Prefer a server-side route that resolves a safe identifier to an authorized index rather than allowing browser-supplied parameters to select arbitrary indexes. The process diagram shows the selection, direct lookup, and rights check as distinct stages.
Understand the Get Document response and a missing key
The official indexing and verification guide shows a REST Get Document request against a named index and document key. It documents an HTTP 200 response with the document JSON when found and HTTP 404 when the key does not exist. A missing record may mean the application passed the wrong key, the content has not been indexed, the record was deleted, or the route targets the wrong index. Do not turn a 404 into a misleading statement that the museum never had the artifact. Log a safe correlation identifier and investigate the source index pipeline. Return a clear not-found state to the user without revealing nonpublic indexing details or treating a failed lookup as permission to perform a broader unrestricted search.
Compare a title query with an exact-key lookup
A title query such as “West Wing restoration” can match multiple records and may change order as documents and scoring settings change. A direct lookup for a known search-document key asks for one specific indexed record. That difference is the center of the visual comparison: multiple ranked candidates on the left and one selected record on the right. Neither path proves that the record is approved for public display; the application must still evaluate rights metadata. A direct lookup also does not guarantee the document is the most recent source-of-truth version if indexing is delayed. The chosen key provides identity inside the search index, not an archival authenticity certificate.
Return only fields the application is allowed to show
The index schema distinguishes retrievable fields from fields used only for other search operations. Microsoft explains that a Get Document response can return fields marked retrievable. That schema behavior is helpful but should not be confused with per-user authorization. If a result contains restricted conservation notes in a retrievable field, a key-based lookup can still expose them to an overprivileged client. Put authorization and field-level disclosure decisions in a trusted application service. Use appropriate read-only credentials or role-based identity for the application, and do not embed an administrator key in a public browser. The museum’s record rights and embargo checks should run before any sensitive fields enter the rendered page.
Handle chunks, aliases, and indexing freshness carefully
An index that stores one chunk per document may return a chunk rather than a complete accession record when queried by chunk ID. Preserve a parent source identifier in the schema and resolve it through an explicit trusted mapping where a full document view is required. Likewise, an index alias or reindexing rollout can change which physical index receives a request. Record the logical collection and the lookup key so staff can diagnose mismatches. Direct lookup reads the indexed representation, which may lag a collections-management database. For conservation status or permissions that can change urgently, consider checking the authoritative record at the time of display. Do not describe indexed content as unquestionably current just because Get Document returned a 200.
Test the detail-page handoff before public release
Use a controlled set of synthetic catalog documents that deliberately share the same display title but have different keys. Search for the title, select each result, and verify that the detail page shows the corresponding key and approved fields. Include a mixed-case key, a nonexistent key, a restricted record, and a chunked source as negative tests. Confirm that 404 handling does not leak private metadata and that an unauthorized caller cannot fetch a record simply by changing the key in the URL. Inspect the index key schema, authentication mechanism, and sources of rights information. Document the test fixtures instead of claiming a ranked query or a direct lookup is secure by definition. The useful guarantee is deterministic identity within a correctly governed application, not automatic permission to publish.
How We Research
We used these primary official sources: Microsoft query types and document lookup overview; Microsoft create a search index and document keys; Microsoft load an index and verify documents; Microsoft Azure AI Search API-key permissions. We checked Microsoft’s document lookup overview, index key schema documentation, Get Document verification examples, and read-only query permission guidance. We distinguished retrieval of one indexed key from a ranked search and from source-of-truth validation. We did not retrieve a real record, test an index or access policy, or verify any production lookup. The figures are conceptual, not screenshots or observed results. Readers should check current vendor documentation and their own security, pricing, and deployment settings. The drawings are explanatory, not reproductions of a vendor interface or evidence of live results.
Frequently Asked Questions
No. It retrieves one indexed document by its exact key without ranking search candidates.
No. The index key is a unique string in the search schema; it may differ from a displayed accession identifier.
Yes. Microsoft documents case-sensitive key values for lookup and indexing.
The requested key was not found in that index; it does not prove the source artifact never existed.
No. The application must enforce document-level rights, field disclosure, and safe credentials independently.