Problem
After updating to version 2025-06, there are some issues with the CDM bindings in our applications.
-
When I want to search for an expression, I cannot find the full expression anymore. In the example, the expression is [policyNumber] " - " [policyName]. I can find [policyNumber] and [policyName] separately but not if I search for the entire expression
-
When I selected an entry from the drop down and want to edit it again, I cannot do so by clearing the text field with the keyboard and typing something new. I need to click on the red X in order to be able to edit it
Are there any settings in the SME to work around this behaviour?
Hi @malena-fleet-rock,
There are a number of different points to cover in your question.
Queries in the Autocomplete
When you enter text into the autocomplete, you are creating a query that is dispatched to Data Services. This query needs to be at least 3 characters long (per-default). This is then sent off using simple_search to find case-insensitive partial matches, see docs.
As you can see in the documentation, " Special characters have no special handling". This means that your query is sent as one single string.
"P000000" → 
will find Policies with policyNumbers that start with “P000000”, e.g. “P000000002”"Polic" → will find Policies with policyNames that start with “Polic”, e.g. “Policy 2”"P000000002 - Policy 2" → 
will not find any Policies as there is no Field Value which returns a case-insensitive partial match “P000000002 - Policy 2”
Reselection
I think this is linked to the Query that you are sending. As there are no Field Values which returns a case-insensitive partial match “P000000002 - Policy”, you need to either clear the selection with the red X or delete enough text that a query returns results.
SME Settings
No, there aren’t any SME settings to change this…
…however a developer can intercept the Query and, for example, separate the queries when you use a space. For example, you could add custom code to convert the query "P000000002 - Policy 2" to something like "P000000002" Or "Policy 2".
Modeling Workaround
I think using expressions are great. However, if you computed this value, the search and query behavior would be as you expect. This is not recommended as it can lead to stale computations / the need to recompute data.
FYI, this is not a CDM issue but rather the general way that drop-down bindings work.
Thank you so much for answering!
We already started implementing something like your suggestion for the queries of expression, so hopefully that solves that issue.
Concerning the Reselection issue: I actually cannot delete any text there and this issue also occurs in drop-down bindings that do not use expressions and where the query does return field values.
Once I have selected an entry from the drop down and I click back into the text field, I cannot delete any character. For example, in the gif in the post, I kept pressing backspace and used Ctrl + A and backspace to delete the content. But as soon as I try to enter a new character, it jumps back to the old entry. So I need to click on the red cross and only then I am able to enter something new.
We have some use cases in our application where we would like to be able to edit the selection and not have to delete the entire entry and reenter it. E. g. one of these use cases would be a dropdown where we have multiple insurers that operate in different countries but have the same name, i. e. Insurer DE, Insurer BE, Insurer NL …
As an end user, I want to be able to change the country without having to clear the entire field and retyping the insurer name as well.
Yes, I can reproduce this in minimal models. What appears to happen is that a new query is sent off as soon as you delete a character. The end user isn’t given the opportunity to meaningfully change the query before it is sent off. Again, this seems to be default behavior which you might be able to customize.
The reselection behavior is a defect in the binding dropdown of relationshipengine-core, not configurable default behavior, and it is still present in the current release.
The mechanism: the Autocomplete widget switches to asynchronous mode as soon as an onSearch handler is passed, which DropDownSelection does in order to query candidates from the server. In that mode the widget keeps the previously selected item as the preselected one and appends the remainder of its label to whatever is typed. Deleting the E from Insurer DE yields Insurer D plus the appended E, so the field renders the original value again. In addition, DropDownSelection puts the selected item back into the candidate list on every render, so the completion source never disappears, not even when the query returns no results. The red X works because it is the only path that resets the selection.
Therefore, I would recommend to create an A12 Bug against RelationshipEngine. A workaround by customization is possible but expensive, because DropDownSelection is internal: a project would have to supply its own template component for the single selection and keep it in sync with every platform version. From my point of view that is not proportionate for a defect in the platform component.
Regarding the expression search, malcolm-silver-ice’s answer holds, and the reason is visible in the code. The label shown in the dropdown is evaluated on the client from the first column of the referenced Overview Model, so an expression like [policyNumber] " - " [policyName] only ever exists in the browser. The query sends the entered text to the server as a simple search over the stored fields, whereby a concatenated label can never match. In addition, there is no client-side fallback: as long as candidates are loaded through onSearch, the widget displays the server result unfiltered and does not match the entered text against the labels either.
Splitting the query into single terms is the cheapest option and it does not require a change to the Document Model. Precomputing the display value into a real field is the only option that makes the full expression findable, however it introduces the staleness problem already mentioned. Which one fits depends on whether the users search by the composed label or by its parts.