Improved Search Performance and Filter Customization

Get Started
Functionality
Learning
Extension
Dev Tooling
APIs
Releases

Release

Author:

Yulia Andreyanova

Changed on:

16 Jan 2026

Target release date:	2026-01-12
Release status:	Development

Description

ONGOING DEPLOYMENTWe are currently updating the content on this page due to an ongoing deployment. Some information might be out of date. Please reach out if you have any concerns.
This release introduces major enhancements to search flexibility, performance, and configurability across the platform.A new account-level default configuration — `fc.mystique.filters.string` — provides centralized control over how wildcard search behaves for all string-based filters. This enables organizations to fine-tune matching logic (such as starts-with, contains, or exact match) while optimizing search performance across high-volume datasets.For use cases that require more specific behavior, individual filters can now define their own field-level wildcard logic using the new `wildcardFilter` property. This two-layer approach ensures that teams can set a standard default while still tailoring filter behavior for fields that require exact searches, backend-safe matching rules, or more restrictive options. Wildcard customization is also now supported inside Complex Filter, ensuring that advanced multi-field filters follow the same flexible configuration model and deliver consistent search behavior across the application.The release also expands the extensibility of the List component through the enhanced `filter.overrides` section, allowing developers to modify labels and replace filter components where needed.Date-based filters now behave more predictably when cleared. Improved internal state management ensures that Date Time and Date Time Range fields reset fully and consistently, preventing outdated values from affecting subsequent searches and giving users a more reliable filtering experience.Form interactions in the Create Custom Wave flow now provide clearer and more consistent validation feedback. The system displays a translatable message when users try to create a wave without selecting any fulfilments. Additionally, a new configuration lets clients define a maximum number of fulfilments that can be selected. If a user exceeds this limit, a clear, translatable message is displayed, and submission is prevented, helping to ensure waves remain practical and manageable.Together, these enhancements deliver faster and more consistent search behavior, as well as greater configurability, for teams designing business-specific filtering and search experiences.

Changelog

Introduced account-level default wildcard configuration (`fc.mystique.filters.string`)
- Defines default wildcard behavior for all string filters. Supports exact matching via `{ "prefix": false, "postfix": false }`.
Added `wildcardFilter` to `fc.filter.string`
- Enables per-field wildcard overrides, allowing more restrictive or more flexible matching rules regardless of the account-level default.
Extended wildcard configuration support to `fc.field.filterComplex`
- The `wildcardFilter` property can be applied inside Complex Filter field overrides, ensuring the same two-layer wildcard model is available for advanced multi-field filter modals.
Enhanced `fc.filter.string.label`
- Now supports additional value types for greater flexibility in filter presentation.
Added `filter.overrides` to the `fc.list` component.
- Allows replacement or extension of filter components, including custom labels and component-level behavior adjustments.
Improved date-filter usability and state management
- Clearing filters fully resets values in Date Time and Date Time Range fields.
- Updated internal state handling ensures consistent and predictable reset behavior.
Enhanced UX in the Create Custom Wave flow
- Added a translatable error message when users attempt to submit without selecting any fulfilments.
- Introduced a new configuration option to define the maximum number of selectable fulfilments (`maxSelectionLimit`).
- Submissions exceeding the limit now trigger a clear translatable error message.

Released capability depth:	Enhancement, Fix
Release bundle / Capability type:	Platform

Use cases

Two-Layer Wildcard Search Configuration for Flexible and Efficient Filtering

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.

Complex Filter Configuration: Tips and Techniques

Renaming Order Tag Filters for Improved Usability

Problem

Order tags (`tag1`, `tag2`, `tag3`) are used for business-level categorization - such as brand, region, sales channel, or internal operational grouping. However, these technical tag names are not meaningful to end users and do not communicate what each tag represents.Because the labels do not accurately reflect their intended business purpose, users often experience confusion. This leads to several issues:

Users must rely on internal training or memorised mappings to interpret tag meanings
Filtering accuracy depends on each person remembering the correct purpose of each tag (e.g., “tag1 = Brand”, “tag2 = Region”)
The UI displays technical labels that do not align with the organisation’s terminology or operational language

Example

Consider EverFresh Foods, a large organic food distributor in the United States that supplies national and regional retailers such as Whole Foods, Sprouts, and local grocery chains.EverFresh relies on several external characteristics to classify and filter orders in their internal system:

Brand - EverFresh, GreenLeaf, NatureBoost
Region - West Coast, Midwest, Northeast, Southeast
Sales Channel - Retail, E-commerce, Food Service
Customer Tier - National Account, Regional Chain, Independent Store

These characteristics are critical for day-to-day operations:

The sales team analyzes orders by Sales Channel.
Logistics teams plan distribution routes based on Region.
Category managers track performance by Brand.

However, in the current system these characteristics appear only as technical tags - tag1, tag2, tag3. Users must remember that:

tag1 = Brand
tag2 = Region
tag3 = Sales Channel

This creates ongoing confusion. New employees have no context for what each tag represents, while experienced users frequently filter on the wrong tags (for example, selecting tag2 = West Coast when they intended to filter by Brand).As a result:

Logistics may group orders by the wrong region
Analysts waste time trying to “decode” tags
The UI shows terminology that does not match the company’s actual business language
Operational errors directly impact delivery planning and reporting

For EverFresh, it is therefore essential that the UI displays the actual external characteristics (Brand, Region, Sales Channel) instead of generic technical labels like tag1, tag2, or tag3.

Solution Overview

To make order filtering intuitive and aligned with business terminology, Fluent now supports renaming tag filters so that they reflect their true meaning.There are two ways to implement this:

1. Screen-Specific Renaming

Using the `filter.overrides` section in the `fc.list` component, teams can rename tag filters only on specific pages where clarity is required.This option is ideal when different teams or workflows utilize tags in varying ways.

2. System-Wide Renaming

If a tag has a consistent meaning everywhere (e.g., `tag2` always means Brand), you can apply a translation-based label update.This updates the label across all screens automatically - filters, drawers, cards, and lists.

Benefits

Users see meaningful, business-oriented labels instead of technical ones
Filtering becomes faster, clearer, and less error-prone
Training requirements decrease significantly
The UI aligns with business terminology, improving adoption and usability
You can choose between system-wide consistency or screen-specific customization

The accompanying how-to guide provides detailed steps and code examples for both configuration approaches.

Improved Search Performance and Filter Customization

Description

Changelog

Use cases

Problem

Where the problem appears

What BluePeak needed

Solution Overview

1. Account-Level Default Wildcard Configuration

2. Field-Level Override for Specific Filters

Support for Complex Filter Fields

Benefits of the Two-Layer Approach

Solution

Configuring Wildcard Search with a Two-Layer Model

Complex Filter Configuration: Tips and Techniques

Problem

Solution Overview

1. Screen-Specific Renaming

2. System-Wide Renaming

Benefits

Solution

Related content

Configuring Wildcard Search with a Two-Layer Model

Fulfilment List Field Component

Yulia Andreyanova

Building Blocks

By Type

Helpful Resources

Quick Links