Semantic Search
Semantic Search lets a workspace search Slab5-native records by meaning instead of exact keywords. It retrieves candidate records from the workspace semantic index, then hydrates the visible result from Slab5 records before showing it to the user.
What Semantic Search does
Use Semantic Search for questions such as:
- contracts with Acme that mention renewal clauses
- support tickets about billing confusion
- open tasks related to onboarding delays
- CMS entries about pricing changes
- activities that look like a customer escalation
Semantic Search complements normal filters and table search. Use filters when you know exact fields. Use Semantic Search when the wording may differ from the phrase you type.
Indexed data
Semantic Search indexes Slab5-native workspace records. The current production release focuses on Slab5 records only. It does not copy raw customer data lake files into Slab5.
The index stores retrieval text, vector values, and metadata needed to hydrate results. Slab5 records remain the source of truth for visible records. Semantic Search does not make the vector index the canonical record store.
Current indexed surfaces are:
| Module | Indexed records | Notes |
|---|---|---|
| CRM | Companies, contacts, deals | Includes names, domains, contact details, status/stage information, notes, and custom fields where available. |
| Support | Support tickets | Includes subject, ticket number, status, priority, category, tags, and description. |
| Projects | Projects and tasks | Includes project key/status/type/description and task status, due date, description, and completion note. |
| Activity | Activity log entries | Includes summary, type, related resource type, and activity body. |
| CMS | Published CMS entries | Includes collection, content type, slug, excerpt, title, and fields. Draft entries are not indexed. |
Products, Calendar, Assets, BI datasets, and external data lake files are not currently indexed by Semantic Search. They may appear in other Slab5 reporting or API surfaces, but they should not be documented as Semantic Search sources until the workspace semantic indexer adds them.
How retrieval works
Semantic Search uses the shared Slab5 Vector Store. Each workspace has an isolated semantic search index. A query to one workspace cannot return vectors from another workspace.
The retrieval flow is:
- Embed the user's search phrase.
- Query the workspace semantic index for the closest record candidates.
- Apply workspace authorization and module visibility.
- Hydrate the visible result from Slab5 records.
- Return the title, module, record type, snippet, score when available, and source metadata.
The vector index is a retrieval layer. Slab5 still reads the record body, status, ownership, and permissions from the primary workspace data store before showing a result.
Setup and readiness
Open Semantic Search in the Slab5 console.
The readiness panel shows:
- retrieval service status
- vector index status
- dimensions
- vector count
- last indexed time
- indexed source breakdown
- source record counts by indexed record type
If the index is missing or stale, use Reindex workspace. Reindexing embeds current Slab5-native records into the workspace search index.
Use Refresh status after a reindex to confirm that the vector count and last indexed time changed.
Using search
Enter a natural-language phrase and select Search. Results include:
- title
- module
- record type
- snippet or match rationale
- match score when available
- source update date
If results are empty:
- try a broader phrase
- confirm records exist in the relevant modules
- reindex if records were recently created or updated
- confirm the retrieval service is available
- confirm the record type is one of the currently indexed sources
- confirm CMS content is published if you are searching CMS entries
Usage and administration
Semantic Search uses the shared Slab5 Vector Store and is metered as Vector Store usage.
Workspace admins can review:
- query operations
- reindex operations
- embedding tokens
- vectors touched
- query scan bytes
- returned bytes
- collection or index-level operation counts where available
Open Usage → Intelligence usage to review Semantic Search usage alongside RAG in a box and other Vector Store-backed surfaces.