Enforcing Contingent Values Against Field Calculator

[VinceE]

I have implemented a series of Contingent Values for a Field Group using a set of domains applied to those fields. Works as expected. I have also implemented an Attribute Rule (Constraint) to prevent Field Calculator from calculating any values for a given field that are outside of the allowable domain values. This gets around the long-standing issue of users breaking Domain limitations with Field Calculator. Great.

The problem is, a user can still calculate an invalid value in a given field based on the allowable contingent values. In other words, the calculated value is perfectly fine for the domain of the current field, but NOT acceptable considering the values in the other fields in the field group.

Manually, this doesn't seem to be possible, since choosing an invalid set of values in the given field group will highlight the field group in red, and not allowing saving the edit--it will throw an error saying "Attribute does not satisfy a required Contingent Value", as expected.

Using Field Calculator, a user can get around this. I would like to prevent this, ideally without setting up a Validation-type Attribute Rule, since I believe a user could also get around that by simply not running those validations (although I'm not well-versed in the "Validation" flavor of Attribute Rules).

Image below:

• Fields Table showing fields and applied domains
• Domains Table showing the two domains (can only show the codes/descriptions of one domain...)
• CV Table showing the allowable contingent value sets
• Attribute Rule enforcing domains in a field, even with Field Calculator
• Attribute Table, with invalid 1-B sets of values, after the Field Calculation

With Field Calculator, it's possible to achieve invalid CVs, even when the Field Group is "Restrictive."

Any thoughts or ways other designers get around this issue would be appreciated. Seems like the only way would be to create custom Attribute Rule Constraints for each allowable Contingent Value... which defeats the purpose of even using Contingent Values in the first place.

[AyanPalit]

@VinceE What is the version of ArcGIS Pro? Would you be willing to share a sample schema with the CV/ARs?

[VinceE]

Sure, I appreciate you taking a look. See zipped geodatabase attached. Example below was generated in Pro 3.0.2. My first post above was done in 2.9.2. Issue is the same.

What I have attached here is slightly different than the example above--this time I'm using three fields in the field group. The issue is exactly the same, however. A user can calculate whatever values they want, which to me, largely defeats the point of implementing CVs. Also, to clarify, the Attribute Rules I have implemented here don't really have anything to do with my issue (I don't think); my question is really just about Field Calculator breaking CVs.

Here's a screenshot that shows how Field Calculator can be used to ignore CVs. The three records shown are all invalid, and would not be possible to enter manually (the red error boxes would show). With Field Calculator, however, they are all happily accepted by the database.

If this is the expected behavior of CVs, please let me know--if that's the case, then that would be the answer to my question. I would also be curious if other users have this issue, or what workarounds might exist.

[VinceE]

@AyanPalit any additional thoughts on this?

[AyanPalit]

@VinceE Thanks for the detailed notes and the sample. I can trace through the steps and reproduce Field Calculator allowing exception to CVs. However, I can still 'Highlight invalid values' from the Attribute Table Menu. Doing so, highlights all invalid combinations containing restrictive fields until a valid combination is entered. 

The intended use case is editing the data per column, per row (manually versus Field Calculate). This is described at Edit fields with contingent values

I agree that it will be a good enhancement to honor CV for Field Calculate as well. Feel free to push this to ArcGIS Pro Ideas.

[VinceE]

Thanks for looking into this and confirming that the functionality is as-expected. I can appreciate the use-case of row-at-a-time editing, but I do think extending this functionality to a full quality assurance strategy could be worthwhile.

A use-case example: as it stands, when I develop schemas to hand off to users to populate, CVs are a nice user-friendly enhancement. But they are apt to fail as a quality assurance measure--a user can still break them pretty easily with Field Calculator. Any user populating a large number of records, then realizing they've made a simple mistake, will be likely to resort to Field Calculator, opening this can of worms.

Perhaps quality controls via data reviewer or custom scripts post-editing are more appropriate for this situation. Again, thanks for the input.

[DrewFlater]

@VinceE I suggest to add a similar discussion to the ArcGIS Ideas site, where others can comment and this idea of enforcing contingent values in Calculate Field can continue to gather other user support.  As a community question, this post has a lifespan and won't be tracked as a development request or priority. 

https://community.esri.com/t5/community-help-documents/arcgis-ideas-submission-guidelines-and-status...