ExpB/AGOL Incorrect List of Field Values

[JoshBerna]

Hello,

I'm experiencing a curious issue with a large (10,000+ features) hosted feature layer dataset when brought into EXPB, as well as in AGOL.

This layer has a field called "permit" representing permit types for parking spaces. A permit name was recently changed from "Family Graduate Housing" (or "FGH") to "Fox," and I brought the service into pro to apply this change to the data.

I had templates for this layer in pro when I was creating it. I went in and selected all features where permit=FGH, and changed this value to Fox. I then updated the template to represent Fox, and everything seemed good in pro.

Upon bringing this layer into AGOL however, the values that were once FGH and changed to Fox now display as <No Value> in the detailed view of the permit field in the data tab of the layer (see "NoValueExample" screenshot). In experience builder, the data does not reflect this change within widgets only. That is, selecting a feature on the map widget brings up the appropriate popup, indicating the feature is of permit type "Fox," but widgets still display FGH as a permit type and not Fox.

I'm attempting to create a filter widget for users to filter by permit type "Fox," but Fox is not an option in selecting values for this field in the SQL expression. "Family Graduate Housing" is still an option, though no features of this permit type still exist (see screenshot: "EXPBuilderIssue").

I'm curious if EXPB is still attempting to honor the original templates present when the layer was published, though I'm under the impression templates don't carry to AGOL. I've waited 24hrs now in case it was a syncing issue, but the problem remains. I also downloaded the data from AGOL as a FGDB, and the table for the layer indicates permit type Fox when brought to pro, rather than <No Value> as seen in AGOL. No domain exists or has existed for this field in pro, and no list exists in AGOL.

I setup a filter and predefined the unique value "Fox," serving as a workaround for the underlying issue. I would like to resolve this to ensure the integrity of the data however.

Anywho, thank you for reading, and any feedback is much appreciated. Let me know if more information is needed.

[DanCopKac]

I think I recently experienced a similar issue. The SQL Builder in Experience Builder was giving me values according to how the symbology of the layer was configured, which was different from what values were actually in the table. 

I solved it by going into the config.json and manually writing my own SQL statements. 

Why can't we write our own SQL statements manually in the UI? No idea. It's actually insane hand-holding in taking away our ability to write our own SQL statements. 

Virtually every app I make requires me to manually edit the config.json files or more because the ability to control different aspects in the Builder interface is soooooo deficient. 

[JoshBerna]

I always forget about ArcGIS Assistant! I was able to edit the json to fix the filter how I liked, thanks @DanCopKac. Now I just have to figure out why this issue is present in the first place...

[JoshBerna]

After some more poking I've realized this may be attributable to some invisible list present within AGOL. Whilst no list or domain was ever present for the permit field, AGOL seems to have generated a list of unique values to be used as the values for the permit field. I am now under the impression that this is the source of the problem, though I'm not sure how to go about resolving this.

From the screenshots below, one can see how no list is apparently present in the data tab of AGOL, but the table indicates a predefined list of options in the visualization tab. This behavior is also present in the edit feature of map viewer, where map viewer seems to be pulling predefined values for the field that are not otherwise evident.

I'm somewhat at a loss here; once again, any assistance is sincerely appreciated.

[DanCopKac]

Is it a public service that can be shared here?

Like I said, in my case it was based on the symbology configurations - which was pre-configured to support several use cases where the data didn't yet exist in the table. 

I believe it was also linked to my symbology being based on every permutation of 3 disparate fields, which produced over 20 conditions for symbology where the data was not in the field at all. 

[JoshBerna]

The drawing info in the rest service is incorrect, still representing Family Graduate Housing and excluding Fox. I have been wholly unable to get this drawing info to update, however. Do I need to utilize the REST API to implement this? I've admittedly began working on a replacement dataset, as this has proved more trouble than is worth at this point, and I can't find good documentation online regarding this.

[DanCopKac]

I think you just have to republish the service, in ArcPro or something. 

[JoshBerna]

Yah that sounds like its going to be the case. Oh well, thanks for your help @DanCopKac.