That new database smell... What would you do with a brand-new blank RE database?
That's all changed recently they've purchased a BRAND NEW Raiser's Edge/NXT database.... And since there is really no conversion needed I've been tasked to help them essentially build a new database from the ground up. It's exciting and cool and it's REALLY weird to see a Raiser's Edge database with no attributes, no solicit codes, no constituency codes and exactly ZERO constituent or gift records.
We'll of course have to enter some of the historical data, but even that is open to interpretation and discussion... So I'm going to toss this out to all you database administrators out there who wish you could start over:
If you were given the chance to start a brand new database from scratch, what ONE thing would you do differently to make your life so much easier?
Comments
-
Besides being a bit jealous...
- Have definite table of constituent codes - restrict entry on creating new.
- Use tables where ever possible for consistent data entry
- Have a plan to use solicit codes - don't record mail/contact preferences in various attributes and other fields within database.
23 -
Pre-define attributes AND their tables.15
-
Below are a few areas that I would suggest thinking about:
- Table fields - think through how you plan to use each and restrict access to add new options (first one to pop in my mind: Relationship/Reciprocal fields on relationship records)
- Gift Entry - How will you use the fields available on gift records? Can you create a gift entry strategy that is clear/consistent and sustainable for 5, 10, 15 years down the road?
- Set and document a standard/best practices upfront; make sure that all data going into the system matches your standard
18 -
Austen Brown:
- Set and document a standard/best practices upfront; make sure that all data going into the system matches your standard
^^^^^ This one!!!!!!!!!!!!
I'd probably invite/make everyone who would be inputting data to get involved with this so that they'd hopefully really be invested in maintaining that standard going forward.
21 -
Create the hierarchy of codes, and the corresponding attributes.
Have a conversation with the other stakeholders about reporting and their needs for getting data out of the database. Be intentional in why we are coding things in a certain way.
Create a manual, policies, and procedures. And then follow them. And use those procedures to train.
Set the expectations accordingly. Be explicit about what will be in the database, and what is not.
On top of the other wonderful answers already given.11 -
My one dream: to have no constituent ID numbers that begin with the number "0". My org bought Raiser's Edge in 2004, and it was set up to have the first two numbers be the year the record was created. I have *many* constituent IDs that begin with 04, 05, 06, etc. This creates HAVOC when exporting data into CSV format (as CSV wants to strip that leading zero). Staff have to be skilled CSV wizards and take additional, non-intuitive steps to prevent the zeros from disappearing.13
-
These are all great, thank you very much!
Consistency of data entry is BIG thing for me, so I'm doing my best. Right now it's a new organization with unknown needs, unknown staff levels (long story) and they are clear on the other side of campus (physical proximity is so under-rated in office environments)... That being said, it's downright weird having so many blank drop down boxes. It took me about three hours to add our first constituent because I kept needing to fill in tables and drop-downs that I took for granted: solicit code, constituent code, addressee fields..
Ugh, Michelle Tribe those leading zeros are killers. We had a group of about a thousand records get imported from our academic database with leading zeros about 9 years ago. I struggled with it for a few years and then I finally gave up and we manually went through and popped a "1" in front of them all. Now we have a thousand records with an extra digit, but it's soooo much easier to work with.9 -
I would make sure that primary addressee and primary salutation are not checked "Editable," because when we change a name, we have to go to Addressees/Salutations tab and uncheck editable and pick the correct one.7
-
This is an exciting opportunity!
A must is a range of SOPs from basic data entry to queries & exports and beyond.
Really getting in there and defining what you are needing to get out of this database and how you are going to put stuff into it.
We are currently in a situation where we "smashed" two databases together last year and they were very different in how things were recorded, updated, etc. Prior to this and during, we worked to create and are still working on numerous SOPs so everything makes since with current and future colleagues.5 -
I like the ideas that others have thrown out. One thing I might do is rethink our Campaign, Fund, Appeal, Package structure. I can see a different structure that would allow us to have better information on what the gift is funding and what brought the gift in. At times, my organization has used Appeal in a way that isn't ideal. And I feel like we could get more out of the Campaign field.
I agree with what Austen Brown wrote. Definitely want to think through the choices you're making to be sure they will last the test of time. So to me that means that your system meets the organization's needs, but in a way that isn't just hyper-specific to how they do things now. That, as the organization evolves, the system will still work for them without them having to make significant changes to how data is tracked. Definitely include other departments in the conversation. For example, if you involve the Finance team, could you devise of structure that makes reconciliations easy?
Also, I'd make a data standards manual as you set up this new database. I'd focus on 1. the system settings you're choosing and 2. defining fields and explaining the business rule type things ("type things" is a technical term - LOL). Things like explaining your security role setup, the Business Rules you chose (like how you'll have IDs numbers generated by the system), or defining what your addressee and salutations formats are. The document will be useful for the people that come after you and can't ask you questions about why you set up the system the way you did.
The database we use was 19 years old when I took over and there wasn't a data standards type manual for me to reference. I can see the effects of different database management regimes through the years. The changes - whether that's changes to what Primary Salutation means, how Corporate gifts are counted, naming conventions on Campaign/Fund/Appeal/Package, or what different Attributes mean (and who maintains them) - those changes can at times make it difficult for us to consistently export data or pull reports from the system.
I've seen you make comments on other people's Community questions. I can tell you're a thoughtful person. I'm sure you're doing the right things and asking good questions. The organization is lucky to be working with you. Good luck as you get them set up.
Chris11 -
I was thinking along the same lines as Chris...at the museum where I first worked in data management, they had converted from RE to Altru, and parts of the Fundraising Hierarchy were not intuitive. At my current organization, we use Filemaker and are converting to RE. Again, I don't find the financial structure we have to be straightforward, so I often have to ask for recommendations from Finance on how to enter a gift. I hope when we convert that the structure we settle on is more intuitive.
In general, setting things up so that when you're gone, the next db manager can understand what they're seeing. Abbreviations might be necessary, but I've seen so many random codes, uninformative segment names, etc. that no one can figure out what they mean. That's years of information that no one knows how to translate!6 -
There are lots of great suggestions here but I will add some more considerations. If you have donations from other countries then set up the correct address formats for the most common ones before data is entered into the wrong fields. Populate those tables with clean data and then lock down access so people cannot change them.
Plan security and user access carefully so no-one else can change your well thought out tables etc.
Set up folders for batches and queries so things are saved in the right places from the beginning.
Come up with naming conventions for queries, reports, batch descriptions etc.
My next advice is even if you are not using webview much at this point still consider it during set up and documentation.
Many fields that have been renamed in NXT e.g. Proposal > Opportunity, Solicitor > Fundraiser, Attribute > Custom Field. see https://kb.blackbaud.com/articles/Article/101288?_ga=2.137461616.1795418374.1582599529-1800974218.1573525515 for a list. You can rename a few database view fields to match, but more importantly use both names in documentation and procedures.
There are also some fields in database view that are not visible in web view so you should not plan to use any of these. e.g. Action Notepad Type - all action notes added in webview have type "Added via RE NXT" so I would not bother adding any other values to this field in database view. Action Notepad Title is also not visible in webview. Address Info Source is another. I cannot seem to find a full list of fields that have been dropped but it would be useful.
Campaign, Fund, Appeal Categories are used as filters for webview reports so set these too.
Attachments are a minefield in web view - they are easier to add but do not show up in database view so can be lost with record merges. Either prohibit adding them in web view or if you are willing to take a risk that some might be lost then make users add an attribute to indicate the presence of attachments in web view. With an attribute you can trigger a warning in database view that there is more information in web view that cannot be seen. Or if you only merge records via webview (new feature) that removes the risk of losing attachments when merging.
Have fun setting it up!11 -
Austen Brown:
- Gift Entry - How will you use the fields available on gift records? Can you create a gift entry strategy that is clear/consistent and sustainable for 5, 10, 15 years down the road?
Specifically in relation to Austen's great suggestions about Gift Entry. What will the policies be around Split Gifts? Soft Credits? Gifts from Donor Advised Funds? Will you use the Bill Connors method for gifts from DAFs and other "pass through" organizations? How will you record gifts from Benevity, etc. where a portion of the gift is subtracted from the gift prior to being delivered to the institution?
6 -
#1. Limit the number of people inputting data to ensure consistency....or make every field possible a drop down without the ability to create new entries. I am still cleaning up messes that occurred 10 years ago when various people worked with me and thought I was just too picky and did it their own way. Luckily our (current) administration sees that only select few should be entering data into fields. Notes and Media tabs are fine for whomever wants to add.5
-
I'd think about reports and reporting needed. That would help define the data fields.
Do lots of training so that all folks are on board
Procedures!!!5 -
-
As mentioned take in what stakeholders say, take it into account, but keep in mind you are building this for all -- and for others to read/interpret/understand and move forward and grow over time after we all have fallen off the planet -- so when setting this up always ask yourself if the codes/tables/codes in the tables, abbreviations (ick!) will make sense to anyone else beyond who might be seeing/using them today.
After inheriting some really, really messy undocumented codes and abbreviations... make sure you write stuff out instead of abbreviate where you can as much as possible and document/keep a log/journal of the acronyms and abbreviations and what the heck they are for (what program/project, when it was etc.)3 -
I agree with all these suggestions and will reiterate the importance of documenting definitions for code tables, const codes, attributes, etc. Additionally, creating procedures for processes and tasks is essential. I recently started a new position and there is not a lot of documentation. That's made the learning curve steeper since I've had to either find the right person to ask (which isn't always the logical person to ask) and or figure things out on my own.
The two things I would add here are:- Training
- Be sure to train the users well. Be thorough and thoughtful in your lessons and find a way to make them fun.
- Don't only teach them the hows, but also explain the whys. I find that people are typically more willing to do things the right way if you explain why it's important things are done a specific way and the consequences of not following the process.
- After the training, be sure and check daily/regularly to ensure that people are following procedures/processes and provide retraining or additional instruction as required. This will help you catch any issues right away and prevent people from getting into bad habits. Plus, nothing is worse than having to go back and fix several months' worth of bad data because you didn't check and make sure people were doing things right from the get-go.
- If someone is making the same mistake over and over, have them help you fix their mistakes. This is one of the best ways to help people learn how to do things correctly, and if they understand the work involved in correcting issues, they'll be more conscientious of doing things correctly the first time.
- Quality Checks
- Set up queries for the most likely/common errors that you encounter during training and run those queries often to identify records that need to be corrected. As mentioned before, have the person who made the mistake help you fix the problem.
- Every time you find a problem in a record, set up a query to find any other records with this same issue. My experience has been that 99.9% of the time, the old adage, "where there's smoke, there's a fire," typically rings true - if you find one record with a problem, there are almost always other records with the same problem.
- Run these QC queries regularly - daily/weekly/monthly depending on your processes - and document the reason for each one and how to fix the issues each query identifies. For ease of corrections, it's typically best for each query to only identify a single issue in a record.
Laura4 - Training
-
I'm a big fan of housing all of my quality control queries, exports and reports in one place using the queue feature (even though I don't schedule the queue), add the queue to my favorites/home page and I run it each Tuesday (even block time on my calendar to do it!).
4 -
Wonder if the full list of database view fields dropped from NXT suggested above by Catherine Burns has been made available? Would be so useful.
We are just embarking on our journey with NXT...wish us luck! And thnkyou all for this insightful thread, it has been most useful.2 -
I actually was looking for that info last week. Could not find anything.
Thought about creating a post/thread where users could create the list since BB hasn't.Think I will - you've motivated me to do so.
2 -
Well, I'm A LOT jealous...That being said, only let ONE person create table entries. I agree with other comments, use tables as much as possible for fields so they stay consistent. I'm still cleaning up messes created when several of my supervisors said 'anyone can enter data, it'll get done quicker that way'...ugh! I'm happy to say that is no longer the case, but I don't think anyone (besides me) realized how long it would take to clean up messes made by people who are now long-gone and had no idea of what they were doing.
Limit constituent codes as much as possible
Limit the areas where your Development Officers can add....notes, actions, etc.
Detailed data entry should be just one person.
Wow! What an opportunity! Good luck!2 -
Lucky you, Tom Klimchak! Great suggestions to everyone who commented. Now that you're a year into it, Tom, let us all know how it's going!0
-
Hi.. I wanted to thank everyone for all the great advice on this post and I wanted give a little update on how things have gone...
It's been a year since we set up an RE NXT database from scratch. Setting up the database was incredibly easy. We sent in the signed paperwork, had a few quick meetings and within two weeks we were given the login to a new, totally empty database. The hardest part of the whole process was convincing various people at Blackbaud that no, we didn't need any sort of "data conversion" work because the organization had only been formed a year before and only really had a few spreadsheets filled with contact info.
The very first thing we did was set up some basic security classes and send invites to the Advancement Services staff and a few key IT people. While our IT department worked on setting up the posting process the Advancement Service staff worked on setting up basic code tables. We also spent a few hours in a meeting with the stakeholders where we talked out some scenarios and thought up some constituency codes and report ideas. Interestingly, the policies, constituency codes and some of the reporting ideas were different than those we used for our University. Each organization is going to customize Raiser's Edge to their unique need, and RE NXT makes that fairly easy.
Next we set up two Campaign codes, then we entered the two Funds and a couple appeal codes. After those were in place we created about 10 constituency codes which we had discussed in those initial setup meetings. With those basic things in place my experienced staff started compiling the constituent and gift info we needed to transfer into the new database.
That first day of real data entry went slowly because we hadn't even considered some of those little code tables we all take for granted. We added in new titles, a few new phone types, another constituency code (all the planning in the world doesn't always prepare you for reality), a bunch of relationship codes and even a couple basic attributes.
We manually entered about 30 board members and existing donor constituent records. Next we moved on to entering our existing gift records (less than two dozen) and we finished out the day by building a few reports where we could total our gifts and compare to our existing records, just to make sure we didn't miss anything.
Over the next six months we ran some imports of constituent records from Excel spreadsheets and we spent about three hours training the BSACAM staff on how to do basic constituent data entry. They picked it up rather quickly and they all found RE NXT to be very approachable.
A year later we now have a little over 2,000 constituents, a few more gifts and a few more reports. We have all our basic code tables in place, we have about twelve different constituency codes and only three custom fields/attributes (so far!). The BSACAM staff can build their own lists in RE NXT and they feel pretty confident in basic data entry.
We keep the stakeholders involved with monthly meetings where we just touch base, have a short training session on a particular topic and usually work through some questions and make policy decisions.
We have some basic documentation, mostly from our meetings, but we haven't written out any expansive instructions because we're still not sure how all the staff positions and roles will play out once we get back into the office in person.
Overall, it's been exciting first year of using our new RE NXT database. As jaded professionals we may not be impressed by simple database functions, but some of the staff were simply amazed by basic reports and lists that were not possible in their old Excel spreadsheets. They love that RE NXT is web based and they can even look up things on their phones. The staff members of our new organization have had an incredibly positive experience and they're excited about seeing their data presented in such an accessible and professional way.4 -
Impressive! Thanks for the update, Tom Klimchak0
-
Congratulations Tom Klimchak, thanks for sharing. Probably the only org on the planet not complaining about the ideas of others.0
Categories
- All Categories
- Shannon parent
- shannon 2
- shannon 1
- 21 Advocacy DC Users Group
- 14 BBCRM PAG Discussions
- 89 High Education Program Advisory Group (HE PAG)
- 28 Luminate CRM DC Users Group
- 8 DC Luminate CRM Users Group
- Luminate PAG
- 5.9K Blackbaud Altru®
- 58 Blackbaud Award Management™ and Blackbaud Stewardship Management™
- 409 bbcon®
- 2.1K Blackbaud CRM™ and Blackbaud Internet Solutions™
- donorCentrics®
- 1.1K Blackbaud eTapestry®
- 2.8K Blackbaud Financial Edge NXT®
- 1.1K Blackbaud Grantmaking™
- 527 Education Management Solutions for Higher Education
- 1 JustGiving® from Blackbaud®
- 4.6K Education Management Solutions for K-12 Schools
- Blackbaud Luminate Online & Blackbaud TeamRaiser
- 16.4K Blackbaud Raiser's Edge NXT®
- 4.1K SKY Developer
- 547 ResearchPoint™
- 151 Blackbaud Tuition Management™
- 61 everydayhero
- 3 Campaign Ideas
- 58 General Discussion
- 115 Blackbaud ID
- 87 K-12 Blackbaud ID
- 6 Admin Console
- 949 Organizational Best Practices
- 353 The Tap (Just for Fun)
- 235 Blackbaud Community Feedback Forum
- 55 Admissions Event Management EAP
- 18 MobilePay Terminal + BBID Canada EAP
- 36 EAP for New Email Campaigns Experience in Blackbaud Luminate Online®
- 109 EAP for 360 Student Profile in Blackbaud Student Information System
- 41 EAP for Assessment Builder in Blackbaud Learning Management System™
- 9 Technical Preview for SKY API for Blackbaud CRM™ and Blackbaud Altru®
- 55 Community Advisory Group
- 46 Blackbaud Community Ideas
- 26 Blackbaud Community Challenges
- 7 Security Testing Forum
- 3 Blackbaud Staff Discussions
- 1 Blackbaud Partners Discussions
- 1 Blackbaud Giving Search™
- 35 EAP Student Assignment Details and Assignment Center
- 39 EAP Core - Roles and Tasks
- 59 Blackbaud Community All-Stars Discussions
- 20 Blackbaud Raiser's Edge NXT® Online Giving EAP
- Diocesan Blackbaud Raiser’s Edge NXT® User’s Group
- 2 Blackbaud Consultant’s Community
- 43 End of Term Grade Entry EAP
- 92 EAP for Query in Blackbaud Raiser's Edge NXT®
- 38 Standard Reports for Blackbaud Raiser's Edge NXT® EAP
- 12 Payments Assistant for Blackbaud Financial Edge NXT® EAP
- 6 Ask an All Star (Austen Brown)
- 8 Ask an All-Star Alex Wong (Blackbaud Raiser's Edge NXT®)
- 1 Ask an All-Star Alex Wong (Blackbaud Financial Edge NXT®)
- 6 Ask an All-Star (Christine Robertson)
- 21 Ask an Expert (Anthony Gallo)
- Blackbaud Francophone Group
- 22 Ask an Expert (David Springer)
- 4 Raiser's Edge NXT PowerUp Challenge #1 (Query)
- 6 Ask an All-Star Sunshine Reinken Watson and Carlene Johnson
- 4 Raiser's Edge NXT PowerUp Challenge: Events
- 14 Ask an All-Star (Elizabeth Johnson)
- 7 Ask an Expert (Stephen Churchill)
- 2025 ARCHIVED FORUM POSTS
- 322 ARCHIVED | Financial Edge® Tips and Tricks
- 164 ARCHIVED | Raiser's Edge® Blog
- 300 ARCHIVED | Raiser's Edge® Blog
- 441 ARCHIVED | Blackbaud Altru® Tips and Tricks
- 66 ARCHIVED | Blackbaud NetCommunity™ Blog
- 211 ARCHIVED | Blackbaud Target Analytics® Tips and Tricks
- 47 Blackbaud CRM Higher Ed Product Advisory Group (HE PAG)
- Luminate CRM DC Users Group
- 225 ARCHIVED | Blackbaud eTapestry® Tips and Tricks
- 1 Blackbaud eTapestry® Know How Blog
- 19 Blackbaud CRM Product Advisory Group (BBCRM PAG)
- 1 Blackbaud K-12 Education Solutions™ Blog
- 280 ARCHIVED | Mixed Community Announcements
- 3 ARCHIVED | Blackbaud Corporations™ & Blackbaud Foundations™ Hosting Status
- 1 npEngage
- 24 ARCHIVED | K-12 Announcements
- 15 ARCHIVED | FIMS Host*Net Hosting Status
- 23 ARCHIVED | Blackbaud Outcomes & Online Applications (IGAM) Hosting Status
- 22 ARCHIVED | Blackbaud DonorCentral Hosting Status
- 14 ARCHIVED | Blackbaud Grantmaking™ UK Hosting Status
- 117 ARCHIVED | Blackbaud CRM™ and Blackbaud Internet Solutions™ Announcements
- 50 Blackbaud NetCommunity™ Blog
- 169 ARCHIVED | Blackbaud Grantmaking™ Tips and Tricks
- Advocacy DC Users Group
- 718 Community News
- Blackbaud Altru® Hosting Status
- 104 ARCHIVED | Member Spotlight
- 145 ARCHIVED | Hosting Blog
- 149 JustGiving® from Blackbaud® Blog
- 97 ARCHIVED | bbcon® Blogs
- 19 ARCHIVED | Blackbaud Luminate CRM™ Announcements
- 161 Luminate Advocacy News
- 187 Organizational Best Practices Blog
- 67 everydayhero Blog
- 52 Blackbaud SKY® Reporting Announcements
- 17 ARCHIVED | Blackbaud SKY® Reporting for K-12 Announcements
- 3 Luminate Online Product Advisory Group (LO PAG)
- 81 ARCHIVED | JustGiving® from Blackbaud® Tips and Tricks
- 1 ARCHIVED | K-12 Conference Blog
- Blackbaud Church Management™ Announcements
- ARCHIVED | Blackbaud Award Management™ and Blackbaud Stewardship Management™ Announcements
- 1 Blackbaud Peer-to-Peer Fundraising™, Powered by JustGiving® Blogs
- 39 Tips, Tricks, and Timesavers!
- 56 Blackbaud Church Management™ Resources
- 154 Blackbaud Church Management™ Announcements
- 1 ARCHIVED | Blackbaud Church Management™ Tips and Tricks
- 11 ARCHIVED | Blackbaud Higher Education Solutions™ Announcements
- 7 ARCHIVED | Blackbaud Guided Fundraising™ Blog
- 2 Blackbaud Fundraiser Performance Management™ Blog
- 9 Foundations Events and Content
- 14 ARCHIVED | Blog Posts
- 2 ARCHIVED | Blackbaud FIMS™ Announcement and Tips
- 59 Blackbaud Partner Announcements
- 10 ARCHIVED | Blackbaud Impact Edge™ EAP Blogs
- 1 Community Help Blogs
- Diocesan Blackbaud Raiser’s Edge NXT® Users' Group
- Blackbaud Consultant’s Community
- Blackbaud Francophone Group
- 1 BLOG ARCHIVE CATEGORY
- Blackbaud Community™ Discussions
- 8.3K Blackbaud Luminate Online® & Blackbaud TeamRaiser® Discussions
- 5.7K Jobs Board