When using the “one of” operator to search for an Appeal ID as the query criteria in web view, results pull from both the ID and description fields. Matches also pull text from anywhere in those fields.

Many organizations use structured, standardized IDs with specific letters/numbers at the beginning, middle, and end of the ID. The current set-up makes it more difficult to get clean, reliable results and can lead to confusion.

When the Appeal ID is selected as the search criteria, results should be limited to the ID field only, not descriptions. It would also be helpful to give users more control over how the match works, such as:

• Beginning of the ID

• Anywhere within the ID

Ideally, this would function similarly to Database View, with support for wildcard-style filtering to make searches more adaptable and precise.

Example:

The organization prefixes all school supply Appeal IDs with “SC” and needs to pull any of those appeals into a query using the Appeal ID criteria with the “one of” operator.

• Web view: When searching for “SC,” results currently include any Appeal with “SC” anywhere in the text of the ID or description, creating a time-consuming hunt-and-select situation with more opportunities for user error.

• Database view: When searching for “SC,” the results only include Appeal IDs that start with “SC.” Those results are simply selected, and the query is ready to run.

Similarly, if Appeal IDs are prefixed with the year and “SC” in the middle of the code (i.e. 25SC___, 26SC___, etc.), users would need wildcard-style searching to return accurate results.