Hi Community,
I'm working with a feature service published through ArcGIS Server and consumed in ArcGIS Online, and I'm experiencing an issue where contingent values are correctly configured and functioning in ArcGIS Pro but are not filtering correctly in any web client — including Map Viewer, Field Maps on iPad, and Experience Builder.
Environment:
- ArcGIS Pro (3.13)
- ArcGIS Server (11.5) / ArcGIS Online
- Clients tested: Map Viewer (new), Field Maps (iPad), Experience Builder
Setup:
- Feature class stored in a SQL-based Enterprise Geodatabase
- Two fields involved in the contingent value relationship: WO_Category (parent) and WO_WorkType (child)
- Both fields are String type with string-coded value domains (i.e. the domain codes are strings such as "DRAINAGE DITCH" rather than integers)
- A field group has been created containing both fields with the Restrict option enabled
- Contingent value combinations are fully defined for all valid Category → Work Type pairings
Behavior in ArcGIS Pro:
Works correctly. When editing a feature directly in Pro, selecting a value in WO_Category immediately filters the WO_WorkType dropdown to show only the valid contingent values for that category.
Behavior in web clients:
Does not filter. All Work Type values are displayed regardless of which Category is selected. This occurs in:
- A brand new web map (ruling out form configuration or widget issues)
- Field Maps on iPad
- Experience Builder Edit widget
Troubleshooting already performed:
- Verified contingent values published correctly by querying the REST endpoint (/FeatureServer/QueryContingentValues) — the contingentValues section is present and all contingency pairs are valid integer index pairs referencing the string dictionary. No boolean or malformed values present.
- Confirmed all Category → Work Type combinations are correctly defined in the contingent value table in Pro.
- Confirmed the field group has Restrict enabled.
- Removed special characters from all domain code and description strings and republished — no change in behavior.
- Tested in a completely fresh web map with no form configuration, Arcade expressions, or widget customization — contingent values still do not filter.
- Confirmed the feature service REST endpoint returns a well-structured contingentValueSets response with all combinations correctly represented as integer index pairs.
Current hypothesis:
Based on the troubleshooting above, we believe the issue may be related to the fact that both fields use string-coded domains rather than integer-coded domains. The REST endpoint encodes contingency pairs as integer indices into a string dictionary regardless of the underlying domain code type — and our hypothesis is that the web client's contingent value evaluation logic may be failing to resolve the mapping correctly when the underlying domain codes are strings rather than integers, even though the published JSON appears structurally valid.
We are planning to rebuild both domains using integer codes to test this hypothesis, but before committing to that work we wanted to check:
- Is string-coded domain support for contingent values in published feature services a known limitation of ArcGIS Server / ArcGIS Online web clients?
- Is there any documented workaround that would allow string-coded domains to work with contingent values in web clients without requiring a full domain rebuild?
- Has anyone else encountered this specific combination (string fields + string-coded domains + contingent values) and found a resolution?
Any guidance from Esri staff or community members who have encountered this would be greatly appreciated. Happy to provide the full REST endpoint JSON output if that would help diagnose further.
Thanks in advance.
David
