Purpose
Enterprise AI needs more than single-datasource queries. Users and workers often ask questions that span customers in a CRM, contracts in a document library, and supporting reference data — with different sensitivity per record. Records search is the governed cross-datasource discovery layer that answers "what exists?" before retrieval-augmented generation or task execution proceeds.
Why it matters
Without a unified search boundary, agents either call each system separately (inconsistent ABAC) or embed vendor-specific query logic in prompts. Records search applies attribute-based access control first, then user filters, then shapes results for the intended AI use case. Every search is auditable — exclusion counts show how much data policy removed versus user filters.
How it works
ABAC-first flow
- A client submits a search with intent, optional resource types, optional datasource keys, and filters.
- The platform evaluates access rules from configured dimensions and grants before applying user filters.
- Results return as record identifiers or full metadata depending on search mode.
- An audit reference ties the operation to compliance logs.
Users never receive records their role and dimensions cannot access — even if filters would otherwise match.
Do: treat empty results as a possible policy outcome — review exclusion metrics and dimension scope before widening filters.
Don't: bypass records search with direct vendor queries when cross-system ABAC is required.
Cross-datasource scope
A single request may span multiple datasources and resource types — for example documents and contacts — when architects have certified both and declared consistent dimension keys. Cross-system foreign keys and static dimension data (see Static data for dimensions) improve join quality for ABAC and search filters.
Search intents
Intents declare why the search runs. The platform uses intent for policy, logging, and downstream routing — not as a substitute for authorization.
| Intent | Typical use |
|---|---|
| retrieval | Gather candidate records for RAG or worker context |
| grounding | Fact-check answers against authorized records |
| analytics | Reporting-style aggregation over authorized sets |
| validation | Data quality checks across sources |
Choose the intent that matches operational purpose; retrieval is the most common for AI context assembly.
Records search vs RAG
These layers solve different problems and work best together:
What this shows: records search authorizes record IDs; vector retrieval scores semantic similarity inside that boundary.
What this is not: a substitute for ABAC — semantic search does not replace policy evaluation at the record layer.
| Layer | Question it answers |
|---|---|
| Records search (RSS) | Which record IDs may this subject see under policy and filters? |
| Vector / RAG retrieval | Which chunks best match a semantic question within an allowed ID set? |
When to use records search alone: you need governed IDs or metadata across systems — for example listing active customers in a region before any embedding step.
Do: narrow with records search (ids mode) before vector retrieval on large document corpora.
When to add RAG: document corpora are large and semantic similarity matters — first narrow with records search (often ids mode), then score vectors only inside that set.
When not to substitute: vector search does not replace ABAC. Starting RAG without an authorized ID boundary risks retrieving chunks from records the user cannot access at the record layer.
Don't: use semantic similarity as a shortcut around records search when policy requires cross-datasource ABAC.
AI context assembly
Role Assistants and external agents should treat records search as the policy gate for cross-system context:
User question
→ records search (intent + filters + ABAC)
→ authorized record IDs / metadata
→ optional vector retrieval on document subset
→ capability execution or answer synthesis
Discover filterable field names from metadata schema services before composing filters — do not guess field names from vendor samples.
Do: discover filterable fields from published metadata schema before composing search filters.
Don't: guess filter field names from vendor sample payloads.
Example
A support lead asks for active customers in Nordics with related contract documents. Records search runs with retrieval intent, customer and document resource types, and a country filter. ABAC removes records outside the lead's region dimension. Returned document IDs feed a vector step scoped to that ID list — semantic search never sees unauthorized files.
Business value
Cross-datasource search gives architects one explainable gate for AI context instead of per-integration prompt rules. Compliance teams review audit references and exclusion metrics. Operators understand when empty results mean policy — not missing data.
Limits
Maximum result limits, intent enforcement details, and MCP parity evolve with platform releases. Metadata schema discovery is a separate step — this article does not list tenant-specific filterable fields.
Dry-run search modes may be available for testing query shape without returning rows. Confirm behavior in your environment before automating dashboards or worker loops on empty-result assumptions.