How to Manage Coded Value Domains for Staff

06-12-2017 11:30 AM
Occasional Contributor

I am wondering how others handle having domains for staff members.  Say you have an organization which does inspections and have a maintenance staff of 50 people.  With moderate turnover, you would end up with a domain (and drop-down list of staff names) in the triple digits before long.  A good number of these names will be associated with old inspection records, but will not be used for new records. 

The names could be removed from the domain list and remain in the data itself, but that would lead to problems upon data validation.  How do you handle this situation with your organization?  Am I forced to deal with a coded value domain with far too many entries compared to what can be used?  Thanks in advance.

0 Kudos
3 Replies
Occasional Contributor II

Hi Justin- if this is primarily to keep a record of users who perform edits / inspections on data within the geodatabase- have you considered editor tracking instead of using domains? Editor tracking should allow you to see which user created the record, last edited the record, along with associated dates of feature creation and last edit: Enabling and managing editor tracking—Help | ArcGIS for Desktop 

It would seem that something like this might be a more user-friendly / management friendly solution to using coded value domains for tracking users and record edits.

Alternatively, the Attribute Assistant add-in might be helpful although I haven't personally used it. Attribute Assistant | ArcGIS Solutions 

Hope this helps!


Occasional Contributor

Hi Rex,

Thanks for the suggestions.  Unfortunately through my workflow (using ArcPad), editor tracking will not work (though I do have it enabled for ArcGIS Desktop users).  For the same reason Attribute Assistant will not work either.  I really am forced to use coded value domains unfortunately.


0 Kudos
Occasional Contributor III

When I had a much more complex situation involving products, companies, and articles, I handled obsolete product references by periodically purging some references and changing others I could not purge fully to something generic. In your case, something like "former employee" might work. In my case, I used vendor independent terms such as "GIS". I recommend doing a domain to table before any purges so you have all the information about the former employee names first.

After the purge I did queries to check that they were indeed gone before removing the products from my file (this was not ArcMap, so my software did not enforce this rule).

Another approach is to archive/remove older data periodically and remove the domain connection in the archive file, and disconnect the archive file from domains.  Bosses tend to like this method because it sounds like streamlining; it makes me nervous because the longer the data has been archived, the farther it may deviate from the current data standards and design, which means it could be hard to get archived data back into useable form if needed.