Two-Layer Wildcard Search Configuration for Flexible and Efficient Filtering

Get Started
Functionality
Learning
Extension
Dev Tooling
APIs
Releases

Use Case

Author:

Yulia Andreyanova

Changed on:

3 Dec 2025

Problem

Search is a critical part of daily operations in Order Management, Customer Management, Inventory lookup, and Store operations. However, not all fields behave well with broad or unrestricted wildcard searches.Historically, Fluent applied a full wildcard pattern (`%value%`) by default across most string filters. While this improved usability, it also introduced several problems:

Performance degradation
Leading wildcard queries (`%value`) prevent index usage and can significantly slow down large datasets such as Orders, Customers, and Product Catalogs—especially when used repeatedly by store associates or automation processes.
Inconsistent query behavior
Not all backend queries support wildcards. Searches such as IDs, references, or specific GraphQL filters fail or return inaccurate results if wildcards are included.
Lack of fine-grained control
Before this feature, developers could not configure wildcard logic per field. This limited the ability to tune search behavior depending on business context:
- Some fields require partial match ("starts with", "contains")
- Others require exact match
- Some must disable wildcards entirely for correctness
Operational confusion
Different parts of the UI behaved differently due to custom or inconsistent implementations, making search unreliable for users.

Example

BluePeak Retail’s customer support team handles thousands of enquiries each day. To resolve issues quickly, agents frequently search for orders or customers using a small set of key fields—for example:

Order Reference (Ref)
Customer Email (PrimaryEmail)
Customer Phone (PrimaryPhone)
Customer Last Name (LastName)

Each of these fields requires a different type of search behavior:

Ref must match exactly
PrimaryPhone also must match exactly
PrimaryEmail typically requires a starts-with match (e.g., typing the first part of the email)
LastName often benefits from a contains search to account for spelling variations

Where the problem appears

Because Fluent historically applied a full wildcard pattern (`%value%`) to all string filters:

Searching for an order reference like `ORD12345` returned multiple unrelated results (`%ORD12345%`)
Typing “smith” when searching for customers resulted in dozens of irrelevant matches (`%smith%`)
Email searches like “john.s” became `%john.s%`, overwhelming agents with too many results
Agents lost valuable time validating which result was correct

This led to:

Longer customer call times
Incorrect records are being selected
Reduced customer satisfaction
Increased backend load during peak support hours

What BluePeak needed

Customer Support required a search experience where each field could behave correctly:

Exact match for identifiers
Trailing wildcard for emails
Flexible matching for names
No wildcard for numeric identifiers

The two-layer wildcard configuration model enables the precise tuning of search behavior, thereby improving speed, accuracy, and overall support efficiency.

Solution Overview

To address both usability and performance challenges, Fluent introduced a two-layer wildcard configuration model that provides precise control over search behaviour.

1. Account-Level Default Wildcard Configuration

A new setting (`fc.mystique.filters.string`) defines the default wildcard behaviour for all string filters in the account.This allows organisations to enforce a consistent policy, such as:

No leading wildcard (better performance)
Allow trailing wildcard (supports “starts with” search)
Full or no wildcard
Any combination required

All newly created accounts can inherit this setting automatically for immediate consistency.

2. Field-Level Override for Specific Filters

Inside any `fc.filter.string` component, the new `wildcardFilter` property allows developers to override the default on a per-field basis.This enables:

Exact match for identifiers
Trailing wildcard for product names
Full wildcard for flexible, fuzzy search fields
No wildcard at all when the backend requires strict input

The override always takes precedence, giving developers full control for complex or sensitive filters.

Support for Complex Filter Fields

Wildcard configuration is not limited to simple list filters. The same `wildcardFilter` property can be applied inside the Complex Filter Component, enabling teams to configure search logic for multi-attribute selectors.This ensures that fields inside complex modals (e.g., “Select Product”, “Select Location”, “Select Item”) follow the same predictable wildcard behavior as list-based filters, improving consistency across all search workflows.

Benefits of the Two-Layer Approach

Improved performance by avoiding leading wildcards where they hurt indexing
Higher accuracy through exact search where required
Better user experience with predictable behaviour across screens
Reduced partner customization, since the platform now supports field-specific tuning
Backward compatibility, thanks to a safe system default

Solution

Configuring Wildcard Search with a Two-Layer Model

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.