Search and filters

Search and filters help users get from a large set of records to the few records that need attention. Search is useful when you know a name, number, or phrase. Filters are better when you know the condition, such as status, owner, due date, tag, or related value.

What the search box searches

The search box is configured separately for each record type. A configurator chooses the direct and related content that can produce a match: for example a title, description, full address, file name, customer display name, line-item note, comment, or attachment description. If no search targets have been configured, that record type has no search box.

Normal input contains 3 to 256 characters and matches one complete substring without regard to letter case. It does not split the phrase into words or rank results. Characters such as %, _, and \ are ordinary text, not wildcards. A record matches when the term appears in any configured target.

Use #number to find a record by its exact generated number, or #{record-id} when you have its exact technical ID. Search reads current data directly, so a successfully saved record, comment, attachment, or file-name change is searchable immediately.

Saved or shared views are useful for repeated monitoring: open requests, overdue work, records assigned to a team, or items waiting for review. Access rules still apply, so different users may see different results from the same filter.

In Parent Tree View, a nonmatching visible ancestor may remain as context for a matching descendant. See Tree View search and filters.

Filters through related records

A table can expose filters for fields reached through ordinary record references. For example, an Aid record may store only a Community while the filter drawer offers Community, District, and Region. District and Region are resolved through the Community relationship; they do not need to be copied onto every Aid record.

Reference filters select records from the entity named by the end of the path. A Region filter therefore opens the existing Region list, picker, or lookup and stores Region record IDs. Breadcrumbs in that picker are display help only; they do not change the field being filtered.

Related sorting follows the same idea. Sorting by Region orders rows by the terminal Region display name. If an Aid record has no Community, or a Community has no Region, that row has a missing value for this sort.

Dependent Reference filters

Some Reference filters use Reference Eligibility and therefore depend on one or more driver filters. For example, a Work Item Parent filter can depend on the selected Type.

• Adding a value-bearing dependent filter automatically adds each missing driver as one top-level equality condition.
• The dependent picker stays disabled until every driver has one value.
• Changing a driver clears values in filters that depend on it. A required driver cannot be removed while its dependent condition remains.
• Each participating driver and dependent appears only once. Null checks do not open a picker and do not require driver values.
• A saved view with duplicate, nested, incompatible, or ambiguous dependency conditions enters a repair state instead of guessing which value should control the picker.

These rules affect how candidates are offered; the resulting query still uses ordinary typed Table filter conditions.

Hierarchy filter values

A Reference filter can use the same Hierarchy Selector as a Form. A fixed path shows its configured levels; a recursive hierarchy adds child levels as you navigate. An ancestor may be available for navigation without being valid for confirmation. Confirming the terminal node writes one Reference ID into one filter condition.

Changing an earlier hierarchy level removes descendants, while reopening a saved view reconstructs the accessible selected chain. Eligibility drivers, record access, archived-record policy, and server validation still apply. See Hierarchy Selector configuration and Reference Eligibility.

Access and archived links

Filters and sorts never expand access. A user must be able to read every required definition and field in the path, and record-level access is enforced while the query runs. Restricted related records are not exposed through matches, totals, ordering, or lookup labels.

Archived linked records participate only when the user has the relevant archive read access. Because access can differ by user, a shared view can legitimately produce different rows for different people.

Configurators can read the complete setup and limits in Record search and Table filters and sorting.