Full-text search index on hosted feature layer attribute doesn't appear to be working properly in EB (AGOL-hosted version)

[BrianFausel]

Since the October ArcGIS Online (AGOL) update I have had problems with attribute-based text searching in Experience Builder (EB). All of the items I am dealing with are hosted in ArcGIS Online, including the application and layers. In these examples there are no items coming from Enterprise.

Problematic item

My Search bar widget in EB is set up to search a text attribute in an hosted feature layer. Problem can also be seen in other Esri apps but I am specifically working with EB in this case.

Problem Description

I have an AGOL-hosted feature layer with a full-text index defined on an attribute and as a result certain types of searches do not work in EB.

Alternatively, if I have a similar but separate feature layer with NO indexes the EB search works as expected. This is the opposite way I would think it would work.

I have 2 public EB apps below that demonstrate the issue. In both try searching for the address string "3805 s casper"

EB app without indexes

EB app with full text index set up

In both apps if you type only "3805" you'll see the desired result appear in the candidate list.

But if you start typing "3805 s" the results will work properly in the app without the index but will NOT work in the one with the full text index. In this case typing "3805 s" says "no results."

The problem has something to do with the search widget breaking change mentioned in the EB blog, as I did not encounter it before the update. I have also read the Searching for Features blog from last November and have not been able to come up with a solution other than to eliminate all attribute indexes. Reading this blog suggests that even a search like "3805 casper" (leaving out the direction "s") should return a proper result when indexes are created.

Is anyone else having a similar problem?

@RussRoberts 

[RussRoberts · Accepted solution]

This looks to be an issue with the EB search widget. The search term is not separating the searched terms apart causing the index to not return results vs. JSAPI widget that Map Viewer and other apps use will break up the search terms and will match how the index has tokenized the terms.  Would recommend creating a support ticket for this.

EB does a fulltext search on search term "3805 s"

JSAPI Search will do search term 3805, search term s

[BrianFausel]

Thanks Russ. I'll investigate the Map Viewer search you mentioned and will definitely contact support to either create a ticket or see if there is one already. Will post any updates I find.

[BrianFausel]

I have opened a support ticket. In the meantime I tested the searching in the web map JSAPI search as you suggested. I saw the same results you did where the index search appears to work. Interestingly I also tested it in a WebAppBuilder app that also worked the same as the web map.

A side-question I have is about the candidate list that appears if a user enters the direction "s" when using the web map JSAPI search. In this example if I just type "3805" I see 4 candidates (which is correct):

If I type "3805 s" then I only see 2 candidates and note that they are ones with words that start with "s" later in the string:

And finally if I type "3805 casper" it finds the correct one. This is actually the ideal behavior and what I would expect from a full text index. But I am still curious why "3805 s" does not show 4 candidates.

[BrianFausel]

I have confirmed with Esri Support that this appears to be a bug in Experience Builder. It was logged as ENH-000163068 if you want to refer to it.

• Synopsis: Experience Builder Search Widget does not honor the Feature layer's Full Text Field Indexes
• Status: In Review

Below is a summary of what I saw while searching for variations of an address string in a text attribute in Experience Builder (ExB) and Web AppBuilder (WAB). In my case the apps and data are all hosted in ArcGIS Online. I haven't done any testing with anything coming from Enterprise.

The example address I am searching is stored in the text attribute as "3805 s casper dr" (address number, direction abbreviation, street name, suffix abbreviation).

• "3805" (left-side start of the string) returns a proper candidate list in all ExB and WAB apps.
• "casper" (street name in middle of string) returns an appropriate candidate list in WAB (with layer index) and ExB (with layer index). The recent AGOL update causes this search to return NO results in ExB (no index on layer).
• "3805 s" (direction included) returns partial results in WAB (with index) - 2 of 4 (?), NO results in ExB (with index) and all available candidates in ExB (no index).
• "3805 casper" (direction left out) returns correct result in WAB (with index) and NO results in ExB (with index) or ExB (no index).

I have only tested address-like text strings but would guess there might be a problem with other types of text.

In my case the workaround will be to eliminate all text indexes on the feature service. This at least allows my users to enter "3805 s casper" to get results they have been used to seeing.

[ShengdiZhang · Accepted solution]

Hi @BrianFausel 

A fix has been installed in a recent update, could you please confirm if that works for you?

Regards,

Shengdi

[BrianFausel]

Hi Shengdi, thanks for reaching out. I can confirm that the recent AGOL update changed the way the searching worked. But I have not had a chance to fully test it yet. Will post an update here when I have a chance to look at it.

[BrianFausel]

Hi @ShengdiZhang 

I completed some testing and can confirm that the searching with hosted feature service indexes now appears to be consistent across Web AppBuilder (WAB) and Experience Builder (ExB). In other words I think the index searching bug in ExB has been fixed.

However, I do still have some remaining questions about how the searching handles single-letter words. I have noticed that if you include a 1-letter word the search candidate list will often not include the right result. Following the examples above and searching on this test ExB app:

"3805 casper" works (which is good and the preferred way for users to search).

"3805 s casper" does NOT work...for some reason the "s" seems to throw it off even though you can see the candidate after you type "3805".

Similarly the test ExB app has searching set up for owner names. If you type a name with single middle initial it does not work but will work if you type first and last name. Try common name "smith" to see some middle initial examples.

This single-letter word search issue appears to be consistent across ExB, WAB, Instant Apps, etc. For me it is not a deal-breaker but I am curious to know if there is any explanation for it.

Thanks!

[BrianFausel]

I recently asked the Esri AI Chatbot (in Support app) about the single-character string search problem. It's answer was that the search "doesn't recognize incomplete or single characters as valid search terms." Not sure where the AI sources that but it was an interesting response.

[ShengdiZhang · Accepted solution]

Hi @BrianFausel ,

Thank you for the detailed test.

I have double-checked with the corresponding team and their response is the same as the Esri AI chatbot. Since a single letter is not a word in the dictionary, it will not be recognized as a valid search term.

We have made a relevant fix in the latest AGOL update (in Experience Builder only) that will not send single letters as search terms.

Can you try that to see if it solves your issue?

Many thanks,

Shengdi