Indexing Behavior

Specifies the unique identifier for the search index as recognized by the AI Search system.

• Must be lowercase and may include only letters (a–z), digits (0–9), underscores (_), or hyphens (-).
• Should be globally unique within the search service.
• Used for all index-related operations and queries.

Selects which Data Elements from the controlling Data Model are indexed for search and retrieval.

• Only the selected elements will be available for filtering, display, and querying.
• Supports hierarchical selection unless the 'Flatten' option is enabled.
• Use this to control which fields are searchable and retrievable in the index.

A combination of the following flags:

Allows inclusion of system-level metadata fields such as Content, TypeName, PageCount, and FlagMessage.

• These fields provide standard information available across all documents.
• Avoid naming conflicts with user-defined Data Fields.
• Use built-in fields to enable full-text search, type filtering, and other common queries.

Computed fields are dynamically evaluated expressions or formulas whose results are included in the index.

• Use for calculated values such as totals, scores, or normalized data.
• Computed fields can be used for advanced filtering, sorting, or display in search results.

Provides real-time metrics and diagnostic information about the index, such as:

• Number of indexed documents
• Storage usage
• Vector index status (if applicable) Use this property to monitor index health and capacity.

Can be one of the following types:

Activates semantic (vector-based) indexing for AI-powered retrieval scenarios, enabling advanced search and retrieval-augmented generation (RAG) workflows.

What This Does

• When enabled, document content is embedded into high-dimensional vectors using a selected LLM-compatible embeddings model.
• Supports both full-document and chunked indexing:
  • Full-document: The entire content (up to the model's context window, e.g., 8K tokens) is embedded as a single vector per document.
  • Chunked index: For large documents, content is segmented into overlapping chunks (e.g., 8K tokens each), and each chunk is embedded separately. This improves recall for long documents and enables passage-level retrieval.
• Optionally includes metadata fields in the vector index for more granular filtering and retrieval.
• Vectorized fields are stored as ContentVector and queried using similarity search (cosine similarity via HNSW algorithms).

Configuration Guidance

• Set this property to configure semantic search options via a Vector Search Options object.
• Choose the appropriate embeddings model for your use case and document language.
• Enable UseChunkedIndex for large documents or when high-recall passage retrieval is required. Note: This will create an additional chunked index alongside the main index.
• Enable VectorIndexMetadata to include selected metadata fields in the vector index, allowing for more targeted semantic queries.

Usage Scenarios

• Enables AI-driven retrieval from the Chat Page, allowing users to ask natural language questions and receive relevant document passages.
• Supports RAG (retrieval-augmented generation) workflows, where retrieved content is used as context for LLM completions.
• Improves search accuracy for unstructured or natural language queries that go beyond simple keyword matching.

Best Practices

• Use chunked indexing for documents that regularly exceed the context window of your embeddings model.
• Test semantic search with representative queries to ensure the embeddings model and chunking settings meet your retrieval needs.
• Consider including metadata fields for filtering (e.g., document type, date) to refine semantic search results.

For more information, see the documentation for Vector Search Options, AI Assistants, and the Chat Page..

Limits the number of pages whose content is indexed for each document.

• Helps control indexing time and storage usage for large documents.
• If a document exceeds this limit, only the first PageLimit pages are indexed.
• Applies only when the Content flag is enabled in 'BuiltInFields'.

Converts hierarchical field structures into a flat schema at the root of the index.

• Useful for integration with search tools that do not support nested fields.
• Cannot be enabled if any root-level field in 'IncludedElements' is a collection.
• Use when a flat field structure is required for downstream systems.

When enabled, new documents of this content type are automatically indexed upon creation.

• Ensures the index remains synchronized without manual intervention.
• The index is also updated for modified or deleted documents, regardless of this setting.

Restricts indexing of HTML documents to a specific subtree of the DOM, defined by a CSS selector.

• For example, set to "main" or "#content" to limit indexing to a specific region.
• Useful for ignoring headers, footers, or navigation elements in web archives or HTML-rendered documents.

Controls access to the search index via the Search Page.

• If not set, all authenticated users may search this index.
• Use to restrict sensitive or specialized indexes to specific user groups.

Defines which AI Generators may be used in conjunction with this index to create new documents from search results using a large language model (LLM).

What This Does

• Allows users to select from a list of pre-configured AI Generators when working with search results.
• Each generator can be tailored with specific instructions, output examples, and quoting methods to control how content is extracted and formatted.
• Enables automated creation of summaries, reports, templates, or other synthesized documents directly from indexed content.

Configuration Guidance

• Add one or more AI Generators to this list to make them available on the Search Page or in downstream automation.
• For each generator, specify:
  • The LLM model to use (e.g., GPT-4, GPT-3.5).
  • Clear instructions describing the desired output (e.g., "Summarize all invoice line items as a table").
  • An optional example output to guide the model's formatting and style.
  • Quoting options to control which parts of the source documents are included as context.
• You can create generators for different use cases, such as executive summaries, compliance reports, or data exports.

Usage Scenarios

• After performing a search, users can select one or more results and run an AI Generator to produce a new document.
• Generated documents can be downloaded in various formats (text, HTML, JSON) or routed to downstream workflows.
• Common applications include:
  • Summarizing key findings from a set of documents.
  • Generating formatted reports or correspondence.
  • Extracting structured data for integration with other systems.

Best Practices

• Provide clear, specific instructions and, if possible, an example output for each generator to improve result quality.
• Use quoting methods to limit the context sent to the LLM, reducing cost and focusing the model on relevant content.
• Test generators with representative search results to ensure outputs meet business requirements.

For more information, see the documentation for AI Generators, prompt engineering, and quoting methods.