We use comments in the gift record to report out restricted gifts. Currently the comment field is not able to be edited after the gift is processed. Therefore any change or miscommunication on the gift cannot be edited to update this.

Please consider also voting for https://renxt.ideas.aha.io/ideas/RENXT-I-8701 to introduce bulk grid editing for all record types! We can ask Blackbaud to replicate database view in web view, but wouldn't it be better if we could IMPROVE them?

Query is not just used as a simple grouping tool to hand off data to Export, Reports, ect. No, Query is used frequently to filter records that need to be cleaned up and adjusted.

Within Query we are regularly opening records and accessing various places on these records to perform needed edits. Why? Because some edits just can’t be done with a Global change/add and creating an Import file is not always practical. As there are many fields which still cannot be adjusted in the Unified View, prematurely shutting off access to Query in database view will make performing needed tasks difficult and unnecessarily burdensome to the customers (us) of Blackbaud.

Customers will now need to have the query open in Unified view and then also have the Database view open to perform such needed tasks -- Unified View Query to filter and group the records on one screen, and Database view on the other screen so we can manually look up and open each record to perform the necessary tasks.

ALL the fields in database view that are coming over to webview at any point need to be viewable AND editable in webview before Query is deprecated in database view. I have no understanding of how your development team would think it would be ok to turn off access to Query in database view before you have replicated all of the functionality that database view query is linked with.

We use comments on telephone, email, links, etc. for several data review functions and these aren't available in any way yet in webview. If the field isn't available to add to a query in webview and we can't get to query in database view, then we lose all ability to use those fields effectively.

Global changes, Exports, etc. in database view need access to query in order to process.

This is really important. I think many of us still find ourselves in database view because there is so much we still can't edit in webview.

We just can't lose query access in DB view before the fields are editable in web view. It's just nonsense to imagine we could do our jobs properly without it. If I could amplify Brent Reed's comment, I would. Maya Rosman has highlighted multiple reasons and multiple fields that are absolutely critical to be editable in web view before db view query is retired.

Honestly, this should be the LAST thing removed from database view.

I've found another field I need to be able to edit in webview that we currently cannot edit. Right now I can see my Education Custom fields in webview, but when I click to edit Education information in webview, I cannot access my Custom Fields. Sometimes we need to make corrections or changes to these after the initial data entry. If I found that a student had been entered without our school ID, I would find that through query, and then seek to add it to their current school's record. Right now in webview, once an Education record is added, you can no longer add custom fields to that education entry or edit the ones that are there. The only way to add the new custom field would be to add an entirely new education record, but most of the time we just need to update a current education record. This is a data integrity issue.

Popping back in to add another missing piece of functionality that I need to exist in webview before query goes away in database view. We use an outside system to process online giving. Our gift processor enters those gifts into RE for us. I run a weekly query to cross-check that that data entry is correct - especially the gift dates. When the gift date in RE does not match the gift date in our online gift system, it causes reconciliation problems with finance. It is VERY easy to accidently miss changing a gift date when doing entry. That's why I have the data monitoring process.

I've been trying to do this in webview query as much as is possible. And it works fine when all data is correct. HOWEVER, I have a gift that was entered as 8/6/25 and should have been entered as 8/5/25. The gift date is not an editable field in webview, which means I now have to open databse view, search for this gift and adjust the gift date there. This gift is not posted and is fully editable in database view, but in webview I cannot access the field.

Gift date editing is critical to our coordination with finance and will impact our audit if we do not correct all dates to match.

I've been reading through the comments and I understand where everyone is coming from (side note: we are VERY passionate about this issue) -but that's from the perspective of someone who regularly handles the daily grind of data cleanup using Database View Query. I'm not sure the core issue is coming across clearly to those who don't work that way, so here's my attempt to explain what we're trying to convey.

I think what may not be clear is this: for those of us who use Query to manage and clean up groups of records, it's essential that clicking on a name in Web View Query drills through to and gives us full edit access to the entire record—just as it currently does in Database View.

If Query in Database View is retired before all fields become editable in Web View, it will force us to constantly switch between interfaces (not everyone has dual monitors) and manually re-search for each record in Database View. This isn’t just inefficient—it’s a major productivity hit, adding unnecessary steps to already tedious work. Plus, Web View is already painfully slow enough when updating records, and adding this extra layer of friction for those of us doing hands-on large scale data cleanup and management is borderline inhumane. (Yes, I know that’s hyperbole—but only slightly.)

Absolutely needed!

If I could vote for this more than once, I would. Also ditto Christopher Horn's comments below. Blackbaud, Christopher took considerable time to set out this useful input for you. Please read his comment in detail.

As to the guest who commented about the timing of such a change----December/January is not a wise time for such changes as that is fiscal year end and the accompanying work for fiscal year close for many organizations. June/July would be far better.

Agree with all the comments below - this is absolutely essential.

Best comment is this: "This is the difference between a part of the system working vs that part of the system allowing us to do our work."

It would also be helpful to not have a massive change like this in the middle of the school/fiscal year. Large changes that make huge impacts to our processes and procedures with auditing and data clean up should happen either in December/January or, preferably, in June/July.

This is so important!!!! Along a similar vein, please also vote for https://renxt.ideas.aha.io/ideas/RENXT-I-8357, "Provide an Open-Field, Tab- and Shortcut-Friendly Option for Data Entry in Web View."

(Note to Blackbaud - Please do NOT merge these ideas. They touch on similar topics, but they are not the same.)

Removing query from database view before all fields are available in web view and before there's a functional multi-field search tool which can use wildcards isn't a great idea for any party involved, including Blackbaud. I'll write an essay on the topic so it's clear why.

Prior to releasing web view query, I would have said that there are a few pieces of missing functionality in web view which actually impede basic functionality in web view rather than requiring tabbing between programs. Namely, the lack of query functionality means a lot of tools are unable to do what we need them to do; the lack of a search tool which can search for multiple pieces of data while using wild cards and partial searches makes it very difficult and sometimes impossible to find records; and missing data fields silo off important information from staff in web view, make web view staff unable to record important data, and makes it impossible to update those fields in web view. (Also the absence of a batch view, but that's not relevant to this.) Other missing functionality just requires tabbing between programs, but those actively make it so work is more difficult or sometimes can't be done in web view. Unfortunately, a lot of these challenges are still present.

As people are trying to explain, forcing a central piece of functionality like query into web view only without database as a backup before all fields are accessible and before search is brought up to standards is going to be a major hit to productivity for administrative and executive staff when reviewing or cleaning any of the missing fields.

That's not actually a small matter: because there are so many missing fields in web view, we've spent many years reviewing basically every record entered into web view in database view to correct important fields. The 'Print Organization Field with Address' field on relationship records is not some niche, unimportant field for example: it defaults to being unchecked, and plenty of mail won't make it to organizational contacts if it isn't printed with the organization name. Sure, some orgs could just global change it, but many of us would want some relationship records to be unchecked while most are checked, so now it involves manual review and editing of every relationship record entered in web view, no matter who it's entered by.

Reviewing such records will now require rather time consuming work arounds: copy and pasting constituent codes from web view into Database View search is time consuming. Creating a database view dashboard for reviewing data in a query would work, but every time the dashboard page has to be opened again, it can take up to a minute to load.

Similarly, relying on the extremely limited search tools in web view for creating queries involving specific records concerns me. Anytime web view search tools can't find a record using one piece of data, which is often, I'm going to have to go into database view and manually search and copy and paste the information back into web view. Much slower and more frustrating, especially when the database view search tools work in query and already have complete functionality.

All of which is to say, until the core functionality problems in web view relating to missing fields and search functionality are fixed, users are relying on database view query to fix the problems created by the core functionality issues in web view. Switching all users to web view query before those problems are fixed will unnecessarily highlight how frustrating those limitations are. I think it will be a smoother process adopting web view over the next year if Blackbaud waits to remove database view query until fixes to long-running issues with web view which touch on the core functionality of entering, finding, viewing, and updating records are complete. Waiting until all missing features which require tabbing between DBV and Web View is less important. After updates to data fields and search, there won't be a problem. But until then, removing all access to DBV Query will, among other things, make the process of fixing problems created by web view slower and more frustrating.

If I could vote for this more than once, I would.

Absolutely going to back up everyone else here. Query is not just a tool for producing mailings, etc. It is a critical function for DBAs to maintain data hygiene. It's impossible in advance to be able to say what fields we'll need to use - basically, if it can be edited in Database View, it needs to be editable in Web View before query in DB view is turned off. Please, please, say something to give us some confidence that you're listening to what everyone is telling you.

Critically important! We can't lose query in db view without this.

This is absolutely necessary. We run multiple audit queries on a daily, weekly, and monthly basis to correct errors, such as mismatched subtypes and campaigns, campaigns and appeals, misspelled packages, missing attributes, gifts that should not post, etc. This is the first step in our month end close process. We must be able to easily identify and edit these records.