Understanding text search

Text search across the Foundry platform, including in Object Explorer, Workshop, and the Functions API, relies on an underlying search engine that processes text through a mechanism called an analyzer. Understanding how analyzers work helps you write more effective search queries and build better search experiences in your applications.

How text analysis works

When a string property is indexed for search, the platform processes its value through an analyzer. The default analyzer, called the standard analyzer (see Lucene StandardAnalyzer ↗), performs the following steps:

1. Splits the text into individual words, called tokens, at whitespace and punctuation boundaries.
2. Converts all tokens to lowercase.

For example, a property value of The Quick Brown Fox is stored as the tokens the, quick, brown, and fox. When you search for quick, the search engine matches this token against the stored tokens and finds a match.

This token-based approach has important implications:

• Searches are case-insensitive by default because all tokens are converted to lowercase during indexing.
• Non-phrase queries match tokens independently. For example, a search for brown fox evaluates the brown and fox tokens separately, so it matches any property containing both tokens regardless of order or proximity. To require the tokens to appear together in order, use a phrase search ("brown fox").
• A search for rown does not match brown because rown is not a complete token.

Analyzer types

The analyzer used for a string property is configured in the Ontology. The following analyzer types are available:

The Language analyzer supports the following languages: english, french, german, japanese, korean, arabic, and combined_arabic_english.

Special character handling in tokens

The standard analyzer treats underscores and periods as part of a token rather than as separators. This means:

• banana_pudding is stored as a single token banana_pudding, not as banana and pudding.
• user.name is stored as a single token user.name, not as user and name.

A search for banana will not match the value banana_pudding when using token-based search methods. If you need to match such values, use a wildcard search like banana* or consider using the whitespace analyzer.

Search in Object Explorer

Object Explorer provides two search interfaces, each with different matching behavior.

Global search bar

The global search bar on the Object Explorer home page and results page performs a token-based search across all searchable properties of all object types. By default, each word in your query is searched independently using OR logic. For example, searching for yellow cab returns objects matching either yellow or cab.

You can modify this behavior using the search syntax features described in Search syntax:

• Phrase search: Wrap terms in quotation marks ("yellow cab") to require an exact phrase match.
• Logical operators: Use AND, OR, and NOT to combine search criteria.
• Wildcards: Use * to match zero or more characters, or ? to match a single character. Both trailing wildcards (term*) and leading wildcards (*term) are supported. Note that combined leading-and-trailing wildcards (such as *row*) are not supported.
• Fuzzy search: Append ~ to a term to find approximate matches.

Property filters in explorations

When exploring a specific object type, you can add keyword filters on individual string properties. These filters offer the following match modes:

Leading wildcard search

Leading wildcard search allows you to find objects where a property value ends with a specific term. For example, searching for *smith matches values such as Goldsmith, Blacksmith, and smith.

Enabling leading wildcard search

To use leading wildcard search, you must enable the Enable leading wildcards render hint on the relevant string properties:

1. In the Ontology Manager, navigate to the object type and select the string property you want to configure.
2. In the property editor, select the Enable leading wildcards render hint.
3. Ensure the Searchable render hint is also selected, as it is required for leading wildcards to function.
4. Save your changes and reindex the object type's backing data sources into Object Storage V1 (Phonograph). You can wait for the next triggered reindex or manually start one from the Data sources tab.

For the full list of available render hints, see Render hints.

Using leading wildcard search

Once the render hint is enabled, you can use leading wildcards in Object Explorer property filters by prefixing your search term with *. For example:

• *smith matches Goldsmith, Blacksmith, and smith.
• *ing matches running, swimming, and ing.

Search in Workshop

Workshop provides several ways to search and filter objects, each with different capabilities.

Filter list keyword search

The Filter List keyword search component supports five search modes, selectable by the user at query time:

For more details on advanced filtering, see the Filter List advanced filtering documentation.

Exploration search bar widget

The Exploration Search Bar widget in Workshop uses the same search infrastructure as the Object Explorer global search bar. It supports the same syntax including quotation marks for phrase search, logical operators, wildcards, and fuzzy search.

Object set filter variables

Object set filter variables support a CONTAIN filter that performs prefix-only matching. For example, if a property value is id000123 and the filter query is id0001, this is considered a match. However, the query d0001 would not match because it does not start at the beginning of the value.

Search in the Functions API

The Functions API provides the most granular control over text search behavior through its string filter methods:

Comparison of search capabilities

The table below summarizes which search capabilities are available in each context:

Common pitfalls

• Partial word searches do not match tokens: Searching for app does not match application unless you use a wildcard (app*) or a prefix search method. This is because the standard analyzer produces the token application, and app is not an exact token match.
• Underscores and periods prevent token splitting: The standard analyzer treats first_name and user.name as single tokens. If you need to search for first within first_name, use a wildcard or consider changing the property's analyzer.
• Multi-word queries without quotation marks use OR logic in Object Explorer: Searching for New York in the Object Explorer global search bar returns objects matching new OR york, which may include results you did not expect. Use "New York" for an exact phrase match.
• Wildcard filters do not analyze the query: When using wildcard search (such as Quick*), the query string is not run through the analyzer — it is compared character-for-character against indexed tokens. This has two consequences:
  • Case must match the indexed form. On a property using the standard analyzer (which lowercases all tokens), a wildcard query containing uppercase letters will not match, even though the original text contained those letters before analysis lowercased them.
  • Multi-word wildcard queries do not match. Because each indexed token is a single word, a wildcard query containing whitespace (such as a search term*) is compared against individual tokens and cannot match. Wildcard searches are therefore effectively limited to single-word queries. For partial matching across words, consider Contour or the Regex mode in a Workshop Filter List.
• Leading wildcards require a render hint: Leading wildcard search (*term) is only available on string properties that have the Enable leading wildcards render hint enabled in the Ontology Manager. Without this render hint, leading wildcard queries do not return results.
• Combined leading-and-trailing wildcards are not supported: You cannot search for *term* in Object Explorer or Workshop. If you need partial string matching, consider using Contour or the Regex mode in a Workshop Filter List.