We rely on these custom fields in database view to establish "contact type" because there are multiple types of communication we send that are not mutually exclusive. As it is the staff that we are encouraging to use web view cannot add (or even SEE!) these codes

We rely heavily on non-constituent attributes (i.e., Custom Fields) to track which relationships should receive specific communications. Since we typically engage with multiple contacts at an organization—each handling different aspects of business with the foundation—we need a flexible way to manage this. Creating constituent records for each contact isn’t feasible due to frequent turnover, which would result in cluttered and outdated records. Additionally, assigning a contact type doesn’t work either, as many of these individuals manage multiple areas and don’t fit neatly into a single category. Several years ago, we consulted with a Blackbaud expert who recommended using attributes (i.e., Custom Fields) on non-constituent records. This approach has delivered excellent results and is now a standard part of our procedures.

This is also crucial for us. We use individual relationship attributes to keep track of different contact types for our mail and email lists. A lot of our org contacts serve different roles across teams, and we need a way to tag these appropriately as a Corporate team contact, a CMN contact, etc. We can't use contact type because it only allows the relationship to have one type, so the attributes give us the flexibility we need to keep them all organized.

I absolutely concur that this is CRUCIAL for those with information in DB view, especially since that will be going away eventually. Honestly, if that functionality isn't transferred, I think we will move away from Blackbaud. That is a MUST have that we have paid for over many many years. It would be unacceptable for that not to be included in the transfer. How does this not have more votes???