Hi Shalimar,

I suspect the key detail here is the Combo Box's filter type.

Since you're already using On filter input change to query your locator service, I'd be interested to know which local filter setting you're using:

• Contains (fuzzy)
• Contains (exact)
• Starts with
• None

From your description, it sounds like the locator API is already returning the correct result (5 E Main St), but the result is being removed afterwards. If that's the case, I wonder whether the Combo Box's client-side filtering is conflicting with the matching logic used by your locator provider.

Have you already tested the different filter modes, especially None? Since the external provider is already responsible for finding matches, additional local filtering may not provide much value and could potentially explain why valid address suggestions are excluded.

Also, can you confirm whether the result is visible in the datasource before the Combo Box displays the options?

I hope this helps narrow down the root cause. If you can share the filter mode you're using, it may help identify whether this is a configuration issue or a limitation of the current Combo Box behavior.

Best regards,

Oswaldo Valles

As I understand it, your requirement is to trigger your Locator API based on the user's search input and display the API response as the dropdown suggestions, without having the Combo Box apply an additional fuzzy-search filter to those results.

Since the Combo Box datasource is loaded/processed by the widget itself, it may not provide the flexibility needed to apply your own search/filtering logic after the API response is received. This is why a valid result such as “5 E Main St” can be removed when the user searches for “5 East Main”.

For this use case, I would recommend using the Mendix widget instead. It allows the search input to be used to trigger your own search logic/API and display the returned values directly to the user as suggestions.

The expected flow would be:

User enters:
"5 East Main"
        ↓
Trigger Locator API
        ↓
API returns:
"5 E Main St"
        ↓
Display "5 E Main St"
as a dropdown suggestion
        ↓
User selects the address

If the API does not return any matching values for the user's search input, the dropdown will simply remain empty rather than applying another fuzzy-search filter to the API response.

This approach should give you more control over the search logic and returned suggestions, while still providing a dropdown-style user experience similar to the Combo Box.

Please let me know if you require any additional information or clarification about the widget, and I’ll be happy to help.

Hi Shalimar,

I think the issue is that the Combo Box is doing a second client-side filtering step after your microflow has already returned the results.

For an address search, I would avoid relying on the Combo Box's built-in option filtering. Your locator API/microflow should be the source of truth for the search.

A setup I would try is:

• Keep the Microflow as the data source.
• Pass the entered search text to the microflow.
• Let the microflow call the locator API and return the matching address objects.
• Disable the Combo Box's Filter option, so the returned values aren't filtered again on the client.

The current Combo Box documentation confirms that the widget has a separate Filter configuration for filtering the options shown to the user, while the data source can be populated independently.

So in your example:

User enters: 5 East Main

        ↓

Microflow
        ↓
Locator API
        ↓
5 E Main St
5 East Main Street
5 East Main Rd
...

        ↓

Combo Box
        ↓
Display the returned results

You don't want another local filter to take 5 E Main St and decide that it doesn't match 5 East Main.

If you need the search box to trigger the microflow on every change, the important part is the On filter input change event. The current Combo Box supports this event, and it also has a configurable debounce interval to avoid triggering requests for every individual keystroke.

I'd start with a debounce around 300–500 ms for an external locator API, then adjust it based on the API response time.

One caveat: if you use a Microflow data source, Mendix applies paging/sorting/filtering for that data source on the client side after the microflow returns its objects. So if you still see filtering after disabling the Combo Box's option filter, check whether another filter configuration is being applied to the returned data.

I would therefore not use a separate Gallery + visibility conditions for this. It makes the UX harder to maintain and you end up rebuilding behaviour that the Combo Box already provides.

If the built-in Combo Box filter cannot be disabled in the exact widget/version you're using, then I'd switch to a Text Input + List View/Custom Content pattern and make the microflow/API response completely responsible for the displayed suggestions. That gives you full control over fuzzy matching and address ranking.

The key distinction is:

API filtering = deciding which addresses are valid results.

Combo Box filtering = deciding which of those results are displayed.

For your use case, you want the first one and don't want the second one to run again.