If the codes are not used by any other system within your organization outside of your Indoors implementation, I would just update my domain to have the same code and description, and then update all of the field values to reflect what's in the new domain value. Here are the steps I'd take:
- Use the domain to table geoprocessing tool to create a new table with the current domain values.
- Use the Table to Domain geoprocessing tool to update the domain with new values having the same code and domain value using the table created in step 1. Just select the description field for both the code field and description field.
- Join the Units feature class and the table created in step 1.
- Calculate values in the Units table category field using the join created in step 3 to update the values to match the description field.
- Remove all the old Code values from the domain.
Yes, this is kind of a hack, but I don't see a way to use Domain descriptions rather than codes because the Configure Indoors Categories doesn't appear to allow us to use Arcade. If we had Arcade in the Configure Indoors Categories, you could just put DomainName($feature,'FieldName') and you'd get the domain description.
I use to be a database purest and would have never recommended this, but between the lack of functionality for joins with branch versioning and the already denormalized schema for Indoors I've come to the point where I've realized that sometimes it's better to make the user experience functional than to worry about a few more bytes of data stored in the database.
