When a GravityView Dynamic Lookup filter works with one choice but fails with several, test the operator and submitted selection together. A multi-select interface can look right while the filter receives only one value or evaluates a different relationship than the reader expects.
Distinguish an empty View from the wrong match set
Before changing ANY, ALL or NONE, confirm that the View is actually visible under its configured search policy. If it is embedded inside another View and the parent disappears before a search, use the nested View visibility matrix. Changing a lookup operator cannot correct a visibility setting inherited by the wrong View.
Once the intended results are visible, verify the returned entry IDs. If those IDs are correct but translating stored choices into labels is slow, use the Populate Anything label-rendering comparison. Keep access, matching and display cost as separate observations.
Check the extension before changing the data
Advanced Filtering 4.10.0, released October 22, 2026, fixes Dynamic Lookup multi-select enhanced-interface filtering with any, all, and none operators. Confirm the installed extension version and the affected field configuration. The older single-selection result is not enough to validate the multi-selection path.
Do not immediately convert the field to plain text or rebuild entries. That can alter the stored relationship and break existing reports. Start with a small staging fixture whose expected matches can be written down without relying on the filter itself.
Write the meaning of the filter in plain language
Suppose a directory stores selected service areas A and B. The requested filter could mean entries with either selected area, entries containing both areas, or entries containing neither. Those are three different questions. The business owner should choose the intended question before the developer changes an operator.
For a selected set of A and B, use four synthetic entries: E1 contains A, E2 contains B, E3 contains both, and E4 contains a different option C. Add an empty entry E5 separately. Whether blank values belong in a none result must be specified and checked in the actual field implementation.
| Entry |
Stored selection |
ANY of A,B |
ALL of A,B |
NONE of A,B |
| E1 |
A |
Yes |
No |
No |
| E2 |
B |
Yes |
No |
No |
| E3 |
A,B |
Yes |
Yes |
No |
| E4 |
C |
No |
No |
Yes |
This is a proposed set-membership acceptance table, not a claim that every field type implements every operator identically. If the product's supported semantics differ from the desired business rule, resolve that mismatch explicitly rather than calling an unexpected result correct.
Illustrative set-membership expectations for a two-option filter; blank values require an explicit business rule. Synthetic explanatory visual.
Inspect labels and stored identities
Record the actual values attached to the selected choices. A label such as North may refer to an entry ID rather than a literal stored string. A renamed display label does not necessarily change that ID. Copy the field configuration and the synthetic entry IDs into the test record.
Avoid choosing numeric-looking labels for the first fixture because they make it harder to see whether the filter compared a label or an identifier. Once the basic matrix passes, add one representative ID-backed choice and confirm the documented matching behavior for that field and operator.
The multi-select label and value guide helps preserve that distinction when the same responses also feed an export. Export correctness and View filtering are separate checks, even when they use the same entries.
Compare the complete interaction
Select A alone, then A and B. Remove A without clearing the whole field and submit again. Finally clear the selection. Record the submitted values and result IDs after each change. This catches stale selection state that a single initial search will miss.
Keep the visitor role fixed during that sequence. Then repeat with the intended public or member role using only records that role may see. An administrator seeing extra entries does not automatically indicate an operator defect. Entry visibility and selection logic both affect the final set.
Deploy a narrow correction
Update compatible components on staging and rerun the same fixture before changing production. If custom filter code is involved, change one transformation at a time and preserve the original stored values. Do not broaden entry access as a workaround for a missing match.
A useful support handoff includes versions, field type, operator, selected stored values, expected IDs, and actual IDs. Keep real directory members out of the evidence. HandL WP can investigate the filter mismatch when those observations show exactly where the requested set differs from the returned one.
Reference and review date
Primary technical reference. Sources checked October 30, 2026. The proposed procedures and original diagrams are explanatory test aids, not claims of customer testing or measured improvements.
Editorial update November 1, 2026: diagnostic distinctions and related guidance reviewed. Existing publication date and illustrative assets retained.