Configuring Wildcard Search with a Two-Layer Model
Essential knowledge
Intended Audience:
Technical User
Author:
Yulia Andreyanova
Changed on:
28 Nov 2025
Overview
This article describes the two-layer configuration model for controlling wildcard behavior in string-based search filters.The new model introduces:- An account-level wildcard configuration (the
`fc.mystique.filters.string`setting) that defines the default wildcard behavior for all string filters - A field-level override (
`wildcardFilter`) inside the`fc.filter.string`component, which allows customizing wildcard behavior for specific fields.
Key points
- Wildcard search can be controlled at two levels: an account-level default that applies to all filters unless overridden, and a field-level configuration that takes highest priority.
- The account-level setting defines the default wildcard behavior across the UI.
- Individual filters can override this default using the wildcardFilter property.
- Wildcard behavior is controlled by two simple options: Leading wildcard and Trailing wildcard.
- Field-level overrides always take priority over account-level settings.
- If no configuration is present, the system falls back to the legacy default: full wildcard search.
- Leaving an option undefined means that the wildcard type is turned off.
- Exact matching is supported by turning both wildcards off.
Account-Level Wildcard Configuration
The account-level setting (`fc.mystique.filters.string`) defines the default wildcard behavior for the entire account.This setting is:- automatically included in all new accounts
- used as the default wildcard configuration for all string filters unless overridden at the field level
1{
2 "prefix": false,
3 "postfix": true
4}
5- prefix (leading wildcard)→ Should the system allow matching text that starts anywhere in the string?
`true`→ Yes, allow searching with a leading wildcard (example:`%abc`)`false`→ No, match must begin exactly as typed
- postfix (trailing wildcard)→ Should the system allow partial matches after the typed value?
`true`→ Yes, allow searching with a trailing wildcard (example:`abc%`)`false`→ No, match must end exactly as typed
Examples
| Configuration | How the search behaves | Explanation |
`{ "prefix": false, "postfix": true }` | `value%` | Searches for everything that starts with the input. Good for autocomplete-like behavior. |
`{ "prefix": true, "postfix": true }` | `%value%` | Searches for the input anywhere inside a string. More flexible but less efficient. |
`{ "prefix": false, "postfix": false }` | `value` | Exact match only. Ideal for ID fields or strict queries. |
Field-Level Wildcard Configuration
Field-level wildcard behavior is configured via the`wildcardFilter` property inside `fc.filter.string`.This always takes priority over the account-level default.1{
2 "component": "fc.list",
3 "props": {
4 "defaultPageSize": 100,
5 "dataSource": "orders",
6 "responsiveness": "card",
7 "filter": {
8 "enabled": true,
9 "overrides": {
10 "status": {
11 "component": "fc.filter.string",
12 "label": "label",
13 "extensions": {
14 "wildcardFilter": {
15 "prefix": false,
16 "postfix": false
17 }
18 }
19 }
20 }
21 },
22 "attributes": [
23
24 ]
25 }
26}How field-level configuration works
| Level | Description | What it means for users |
Field-level (`wildcardFilter`) | Highest priority | This is used first. If defined, it overrides all other configurations. |
Account-level (`fc.mystique.filters.string`) | Default for the entire account | Only used when no field-level override is present. |
| System default | Fallback | Full wildcard search (`%value%`) only if no other configuration exists. |
