Filter card

With the Filter card, you can perform a keyword search across all properties of the object types in the analysis path.

The available search and filter types are described below:

Keyword search: Type directly into the search bar and press Enter to search for a particular value across all data in the analysis.

Property search: Enter or choose a property from the dropdown menu to further define in the filter card. The default for each property is an exact match search type (is), but you can change this to a different parameter depending on the property type. For example, you could change a filter from Project Start Date is May 15, 2023 to Project Start Date is between Jan 1, 2023 and Dec 31, 2024.

Filter on linked property: Filter on the properties of a linked object type without traversing to those object types. Select the On a link option at the bottom of the filter property dropdown menu to choose an object type linked to one or all object types in your analysis. Then choose whether to search for properties of an object type in your analysis that is linked to or is not linked to the selected linked object type.

Special property types

Additional property types, such as vector, leading wildcard, and regex properties, appear at the bottom of the filter card when present in your analysis. For more information about regex searchable properties and syntax, review the search syntax documentation.

Leading wildcards

Leading wildcard search lets you find values that end with a given term. For example, a query of *smith matches values such as Goldsmith and Blacksmith.

To enable leading wildcard search on a string property:

1. In the Ontology Manager, open the object type and select the string property you want to configure.
2. Enable the Enable leading wildcards render hint on the property.
3. Confirm that the Searchable render hint is also enabled, 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.

Search matching

When a search query is entered, it is broken into individual units called tokens. For example, The Quick Brown Fox produces four tokens: the, quick, brown, and fox. Note that tokenization is case-insensitive.

Underscores and periods are treated as part of a token rather than as separators. For example, banana_pudding is stored as a single token, so a query for banana will not match banana_pudding without a wildcard. Dashes, in contrast, are treated as token separators by the standard analyzer — a value like well-known is broken into two tokens (well and known). This is a common source of confusion when searching for hyphenated terms or formatted identifiers (such as UUIDs), because the query is split into separate tokens that are matched independently rather than as a single connected term.

For a detailed reference on analyzer behavior, analyzer types, and how text search works across the platform, see Understanding text search.

Search types

• is: Signals an exact match against non-analyzed text. For example, The Quick Brown Fox will only match The Quick Brown Fox.

• starts with: Appends * to the lowercase search term and matches against non-analyzed, raw field values.

• contains: Uses partial matching on the final token. All tokens in the query are matched exactly against the target field, except for the final token, which is matched as a prefix. This allows results to appear before the final word is fully entered.
  
  Example:

  The search term The Quick Brown F searches for records containing the, quick, and brown as exact matches, and any word beginning with f as a prefix match. This would return a record containing the brown fox reached the quick rabbit, as all tokens are present and fox satisfies the prefix match on f. It would not, however, match the fox quickly jumped over the brown fence. While fence satisfies the prefix match on f, the token quick is not present, as quickly is not considered an exact match for quick.
  
  The order of tokens is not considered when evaluating matches. All tokens must be present in the target field but may appear in any position. This search behavior applies to text-based properties only.
  
  

• contains any word from: Uses the multi-match filter. An object matches if the search tokens exactly match any token from values in the given property.
  
  Example:

  For the search term The Quick Brown Fox, queries for the OR quick OR brown OR fox.
  
  This search will match: brown vehicle, fox hole, the quick fox ran through the forest
  This search will not match: brownie, foxtrot, Many foxes move quickly
  
  

• contains phrase: Uses a phrase filter that requires tokens to appear consecutively in the exact order entered.
  
  Example:

  A query of The Quick Brown Fox would match The quick brown fox is climbing the tree, as the four tokens appear consecutively in the correct order.
  
  This search will not match:

  • The Quick brown foxy bear: The token fox is not present as a standalone word.
  • the brown rabbit met the quick fox near the river: The tokens are present, but not in the correct order.
  • the quick smart and fast brown fox: Additional words appear between the tokens.

Common pitfalls

• Partial-word searches do not match exact tokens: A query of app does not match application with the default is search type, because the standard analyzer indexes application as a single token and app is not an exact token match. To match values that contain a word starting with your query term (such as app matching application), use the contains search type, which treats the final token of the query as a prefix and performs the wildcard search for you. To match a sequence of letters that appears in the middle of a word (such as cat inside application), none of the standard search types will match — you would need to use a regex pattern such as .*cat.* against a regex-enabled property.
• Wildcard queries are not analyzed: When you use a wildcard search (such as Quick*), the query string is compared character-for-character against the indexed tokens rather than being run through the analyzer. As a result, the case of your query must match the indexed (lowercased) form, and multi-word wildcard queries do not match because each indexed token is a single word.
• 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.