Dynamic Domains Based on a feature class || Allow to select a field within the relationship class to be displayed on the destination instead of id

[ChiefMaster]

We need a feature that can update Dynamic Domains automatically based on the value of a specific field in another feature class. This feature will allow the user to choose which field they want to use as the display field for the Dynamic Domains. For example, if the user has a feature class of cities and another feature class of countries, they can use the country name field as the display field for the Dynamic Domains of the cities, based on the country field.

================

Another Suggestion

================

When the user creates a relationship class between two feature classes, they should be able to select a field from the origin feature class that will be displayed on the destination feature class, instead of the foreign key data. For example, if the user has a relationship class between cities and countries, they can use the country name field as the display field for the cities, based on the fk_CountryID field. The user should also be able to choose the value of the display field from a drop-down list with a filter, similar to how domains work. This will help the user avoid typing errors and make the relationship class more efficient and user-friendly. This feature will also encourage the GEO DB users to use the relationship class functionality more often.

[MErikReedAugusta]

This would be a cool feature, so I'm tentatively giving it a kudo, but it also seems like it would be really complicated to implement & manage.

My gut inclination is that Attribute Rules might be of use, here, but I don't know if you can get at the Domains through them.  I'd imagine likely not, given that AR are written in Arcade.  If they were written in Python, I might see a way to do it, but it'd be pretty volatile and risky.

[ChiefMaster]

@MErikReedAugusta 

I don't think it will be at this level of complexity in implementation.

ESRI has previously developed the domains system, and there is a GP tool for generating domains. If only those GP tools are changed to list the domain values from another feature class, it will be a significant gain in terms of avoiding breaking the relations and reducing the number of domain values that must be updated on a regular basis, which is a good practice for any relational database.

[Bud]

Related: 

1. Use SDE table as Domain Table
2. Use database view as domain
3. Improved Coded Value Domain Sorting Using SQL Statements
4. Oracle: Select domain codes/descriptions using XMLTABLE instead of EXTRACTVALUE.
5. Is there a way to update a domain, when a Feature Class is updated?

   • What kind of geodatabase? If you are using an enterprise GDB (or maybe a mobile GDB) the you could query using SQL to compare the FC values against the domain values. …and use a scheduled task and Python to insert a new value into the domain.

[Bud]

Should this idea be split into two separate ideas?

[ChiefMaster]

Yes, we can split them but just imagine if they merged to one idea to be the dynamic domain field the same field of the relationship class.

I believe it is the best value we will gain from the relationship and its domain constraints which created above. 

I Post them together to give anther idea to ESRI Community if they merged! 😄  

@Bud