AEM Forms custom filters must prove search, not just render

An AEM Forms 6.5 team wants three custom String fields in the Forms and Documents filter panel. The tempting shortcut is to see a new input on screen and call the search finished. In a recent Experience League thread, an Adobe employee pointed out the distinction: a DAM Property Predicate can render in that panel while its metadata path or matching behavior still needs proof.

Find the field that users actually search

Record each custom property's repository path, type, sample values, and the console where people expect to search. Do not assume a configuration that works in the Assets search rail also controls Forms and Documents. Adobe's Search Forms guide describes the Property and Options predicates and where console configurations are stored. It also says to keep customizations under /apps, leaving /libs alone. Start with one property, not all three.

Test the predicate against real form metadata

The community's accepted answer identifies a DAM Property Predicate pointing at jcr:content/metadata, with partialSearch and equalsIgnoreCase configured. Check that the configured name matches the actual stored field on several forms. Search an exact value, a partial value, and a different letter case. Include a form that must not match. Compare the result set with the repository values, then repeat after indexing settles. A text box appearing in the filter panel is only a UI test.

Make the choice usable

If the property has a controlled vocabulary, an Options Predicate may be clearer than free text. If the Forms console does not honor the DAM predicate in your release, document the failed query and use a Forms-specific extension path or Adobe Support rather than modifying a shared /libs component. Ask the implementing partner for a small test matrix, deployment package, and evidence that each filter returns the right forms.

Adovo’s view

A filter is a promise that the right content can be found. A visible control without verified results spends users' trust. Design the metadata path, search behavior, and author experience as one contract; prove the contract with a positive and a negative form before scaling it.