Fluent Commerce Docs

Content in this track:

Content in this track: Configuring Wildcard Search with a Two-Layer Model

Essential knowledge

Author:

Yulia Andreyanova

Changed on:

29 Jan 2026

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.

Both layers work together to enhance search performance and flexibility, while providing teams with control over how partial or exact matching should be implemented.

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

What this means:

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

If a value is missing

If the configuration omits either parameter, it is treated as false — meaning that wildcard will not be applied.

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.

System default (when neither setting nor field-level override is defined)

If neither the global setting nor a field-level override is defined, the platform uses full wildcard search (`%value%`) to keep backward compatibility.

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}

What this does:This forces an exact match search for the Status filter — even if the global setting allows partial matching.

Important behavior

Any missing (`undefined`) value in the field-level config is treated as false → That wildcard is not applied.
Setting both values to `false` gives you an exact search.

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.

Content in this track:

Configuring Wildcard Search with a Two-Layer Model

Filter Panel Component

Complex Filter Component

Select Field Component

Multi-Value Search Component

Filter Panel: Configuration, Customization, and Best Practices

Complex Filter Configuration: Tips and Techniques

Using Predefined Values in Order Tag Filters

Rename Order Tag Filters to Business-Friendly Labels

Enable the Status Filter with Predefined Values

Configure Relative Date Filtering and Default Timeframes

Building Better Filters: From Reusable Components to Customer Search

End Of Track

Configuring Wildcard Search with a Two-Layer Model

Configuring Wildcard Search with a Two-Layer Model

Overview

Key points

Account-Level Wildcard Configuration

Examples

Field-Level Wildcard Configuration

How field-level configuration works

Related content

fc.mystique.filters.string

Yulia Andreyanova

Knowledge Tracks Related To This Topic

Building Blocks

By Type

Helpful Resources

Quick Links