Raiser’s Edge Code Table Guidelines with Omatic’s Amanda Tetanich

Amanda Tetanich (bCRE) is an Omatic Software Consultant that also knows Blackbaud products inside and out. Prior to her work at Omatic, she held several roles in Customer Support and Training at Blackbaud, including being the Product Lead for Blackbaud’s Target Analytics®. Today, Amanda is an expert at helping organizations implement ImportOmatic. Let’s catch up with Amanda to learn the best tips and tricks for managing your code table entries.

If you could give your clients one major tip to enhance their use of Raiser’s Edge^TM, what would that be?

Refrain from adding unnecessary code table entries! I find that people want to get more and more granular with code tables from constituent and solicit codes to phone types. Boil it down to what’s useful and practical, and try to keep those code tables clean. This is how many organizations end up with messy data. Then, they discover the mess when the time comes to pull a list and 17 different phone types have to be included to get what they need.

So, how do you determine if a code table entry is unnecessary?

That’s the tough part. Sometimes the easiest way to identify a problem is to turn a critical eye on otherwise mindless data entry. Where are you having to scroll down a long list of options? Where do you consistently type the “wrong” entry or have to search for the correct wording? When do you use “one of” operators in queries? The longer we work around a problem, the less we notice that it IS actually a problem. Turning off auto-pilot can often be enough to draw attention to the database’s weaknesses.

If there is a desire to add a new code table entry, what questions should be asked to make sure it is necessary?

1. Is there something that already exists that we can use or modify, rather than adding a new entry? For example, if we are adding “Cell Phone” to our phone types table, should we just edit the existing “Mobile Phone” to represent the more modern terminology rather than adding a new value altogether?

2. How do we plan on using this data point differently than what we already have? Do we need this for queries or reports? In my experience, “more specific data” does not always equal “better data.” Too many entries can complicate queries and reports, not to mention confuse users and increase human error.

Are there any code table entries you have seen in your consulting work that you would strongly discourage?

Yes – I see organizations get far too granular with phone and email types. Times are changing. We’re moving further and further away from a need for both home and cell phone numbers, and moving toward just using primary and alternate numbers.

If someone realizes their code tables are a mess, what is the best way to start the clean-up effort?

Anytime I’m considering cleaning out part of my database, my first step is always a thorough analysis of the problem. Measure twice, cut once! It allows you to see how frequently a table entry is being used in your database, so you can make an informed decision before removing it. On top of that, it will let you merge table entries right there within the tool.

What’s the best piece of advice you’ve ever received?

My father always said “work smarter, not harder.” If there’s a smart way to do something that will save time and prevent mistakes, then by all means do it!

When you aren’t helping organizations work smarter, what can we find you doing?

I like to hop on my bike and ride down to the coffee shop to work on a crossword puzzle, read, or people watch. I also enjoy relaxing at home and watching The Food Network… as long as I’m not on a diet.