It would be extremely beneficial to enhance the search functionality in Webview by adding an "Advanced Search" option, similar to what’s available in the Database View.
Currently, the Webview search is quite limited and often returns partial or overly broad results. For example, when searching by Constituent ID, the results may include any record where those digits appear in other fields, such as Alias or other IDs — with no way to filter for exact matches.
Suggested enhancements include:
An "Advanced Search" panel in Webview
The ability to search by key fields such as:
Constituent ID (with exact match checkbox)
First Name
Last Name
Address
City
Postal Code
Phone Number
Inclusion of checkboxes or filters to refine search (e.g., "Exact Match", "Starts With", "Contains")
Optional ability to combine criteria for more targeted searches
Why this matters:
Improves efficiency when searching for constituents in large databases
Reduces frustration caused by unrelated or partial search results
Aligns Webview functionality with the more robust features in the Database View
Supports data quality, clean-up, and user experience for teams across fundraising, data management, and support
This would be a valuable improvement for organizations transitioning more of their work to Webview and trying to streamline workflows.
Thank you for considering this enhancement!
Definitely agree a power search in webview would be great. It would also be wonderful for it to search gift records. In so many instances I have to create queries when I think a search should be available. For example, searching a check # or transaction ID.
I use this all the time - especially regarding being able to search by email address - it helps find associated records
This is essential for handling duplicate records. I find it so much easier to search for constituents in the database rather than in web view because of all the options available. AI is not the solution for this.
This is essential! AI is not the answer for everything. Searching using more than one field is key especially when searching for a constituent with a common name OR we may need to search on the email field if we have an email address but not a full name of the constituent. Having to run a query to locate these records is not efficient.
I also second Sunshine's examples in her post of Jan 7, 2026.
This is absolutely essential for handling dupes and spouses. Database view Deduping tool could find unconnected spouses, but the webview version cannot. Advanced search fields help me find them as they come up. Please!
Advanced search is a core functionality, and needs to be treated as such.
And to reiterate others' comments, AI is a non-starter as a solution for this vital need.
Need - AI is not a viable alternative - Maya Rosman has got it exactly right in post below!
This is essential! I use the search by email address often to search for all constituents with the same email address on their records, including non-primary email addresses, to check for duplicate emails.
Also, orgs names can change, so to be able to search via aliases/past names, is very important in avoiding duplicates.
This is really needed!
AI is not a solution for this. We need the ability to define the search criteria on our own!
I would LOVE this so much. Even just postcode getting tacked on would CHANGE MY LIFE
PLEASSEEEEEEEEE!!!!!!!!!!!
Needed ASAP!
Essential!
I am commenting again. And honestly, Maya said it so well below.
DB admins move fast, you guys. We're not opposed to change, but we don't want a five second task to take two minutes. Sure, that doesn't sound like a lot - until you understand how many five-second tasks we knock out one after the other.
I'm commenting again following the PSG hosted town hall where we were told that Blackbaud envisions that AI chat will replace the need for advanced constituent search in webview. I am STRONGLY against that as a solution, especially since not all institutions will enable AI (currently our college's AI guidelines don't allow for this for us).
But more specifically because this is an awful solution for a basic core system function. We need to be able to select multiple search terms (including partial name, street address number and partial address, emails using wildcards, etc.). All of this is completely straightforward to do in the advanced search in database view currently and prevents duplicates (sometimes I cannot find the record I need using the current webview constituent search but find it immediately in the advanced search in database view). Writting every part of a multi-field search that I need into AI chat in a sentences is an unnecessary and frustrating layer between users and the data.
Please seriously reconsider this path and give us the functionality we've always depended on to have fidelity of records and lower the possibility of duplicates without putting AI between your users and the answers they need.
I second both of Sunshine's January 7, 2026 examples as indicative of the need here.
We need these search options to make our searches quicker and easier
I am commenting again to share two examples I have run across lately:
Many churches and franchised stores have the same name, so my client needs to search at least two different fields narrow down the results, which isn't possible in web view.
When I search for a constituent ID the search returns any IDs with matching digits instead of the exact match. Note that not everyone wants an exact match when searching for an ID, but an exact match checkbox would help for this example.
There are many people that I would easily be able to find in DB view with wildcards and partial info that I can't in webview.
If functionality isn't improved in webview, this will be a significant add to my workload where I would have to go in and query for what is very simplistic information, that shouldn't need a query.
Searching in NXT rarely pulls through records. Searching in Database view is still having to take place so we can be more accurate. It is vital that we can search by the same categories, and not just a generic search that only works on names, occasionally email.