Hi Everyone, For our deployments at Berkeley, we needed to have the new computedCurrentLocation field be searchable from the advanced search screen. This turned out to be complicated but doable. I'll share a technique for making it work, in case you would like to do it too. The reason this turns out to be complicated is that in the app layer, computedCurrentLocation is configured with a ui decorator called valueDeURNed: <!-- This is what we want for the record editor --> <field id="computedCurrentLocation" ui-type="valueDeURNed"/> That decorator causes only the display name part of the field value (which is a refname) to be displayed, and also makes the field read-only. On the record editor, this is the correct behavior. The problem is, if we simply configure the field to be searchable: <!-- This doesn't work --> <field id="computedCurrentLocation" ui-search="repeatable" ui-type="valueDeURNed"/> The valueDeURNed decorator is also applied on the advanced search form, creating a read-only field that's unusable. The desired behavior on advanced search is to have an editable autocomplete field, which requires a different app layer configuration: <!-- This is what we want for advanced search --> <field id="computedCurrentLocation" ui-search="repeatable" autocomplete="location-location"/> There isn't a way to configure computedCurrentLocation both ways, with one configuration taking effect on the record editor, and another on the advanced search screen. The solution is to create a new, app-layer-only field that maps to computedCurrentLocation for purposes of search, but doesn't appear on the record editor. This is the same technique I've previously described, for configuring a field to have both wildcard and range search on the advanced search screen. It looks like this: <!-- Create a new field for advanced search --> <field id="computedCurrentLocationSearch" ui-search="repeatable" autocomplete="location-location" exists-in-services="false"> <services-tag>computedCurrentLocation</services-tag> </field> The services-tag element tells the app layer that in the services layer, our new computedCurrentLocationSearch field maps to a different name, in this case computedCurrentLocation. The exists-in-services="false" attribute seems contradictory, since having a services-tag element implies that the field does exist in the services. In actuality, this attribute only controls whether or not the field is sent to the services layer when the record is saved. Since we won't be adding computedCurrentLocationSearch to the record editor, we don't ever want its value to be saved to computedCurrentLocation, because it will always be empty. However, when exists-in-services="false", the field is still sent to the services layer in search queries. At this point, computedCurrentLocationSearch can be added to the cataloging advanced search form like any other field. The value typed into that field will be mapped into computedCurrentLocation when the search query is generated, which produces the right behavior. This technique would work in any situation where a field needs to be configured differently for the advanced search form than the record editor. Another use that comes to mind, although it hasn't been tested, would be to make boolean fields work on advanced search, by presenting them with a (none/true/false) dropdown instead of a checkbox. Thanks, Ray