ABC’s of the Raiser’s Edge:”E” is for Exclude

 The ABC's of the Raiser's Edge

All of the standard reports in the Raiser's Edge, as well as all mail functions, allow your organization to exclude

records from that report or mailing based on a variety of  record type Attributes. That's one of the primary reasons for using Attributes effectively. Attributes are incredibly powerful little tools that can often eliminate the need for a query. In fact, when coupled with the Create an Output query tool, they can even create queries for you! What a deal, right?

Let's take a look at a couple of examples of how excluding records based on Attributes might be helpful. In the first example, your organization tracks Gifts that are paying for auction items as a Yes/No  Gift Attributes. Your development director does not want those Gifts included in the Gift Detail and Summary reports you are creating for her for the next Board meeting. Using the Attributes tab of the report, you simply choose to Exclude gifts with an attribute of Auction Item=Yes! It's that simple! No standing on her head to write some complex query! No worrying about having to hold your mouth rightwink


Here's another one. In your database, Volunteers are tagged with a Constituent Code of Volunteer, and Volunteer Interest is tracked as a table (drop-down) value Constituent Attributes . In preparing to send a mailing to request Volunteers for your upcoming carnival, you don't want to mail to your Golf Tournament volunteers. After all, you want to save them for the golf tournament, right? So, after filtering on Constitutent Code=Volunteer, you can use the Attributes tab to further filter out your golfers by excluding those with a ConstituentAttributes of  Volunteer Interest equal to Golf.


 Do you have some creative ways to you can share to Exclude records from mailings or reports? I bet you do!!

The ABC’s of the Raiser’s Edge:”D” is for development database

The ABC's of the Raiser's Edge

…and also for DAH!

Everybody knows that the Raiser's Edge is a development database, right? Everybody knows that it was designed specifically for fund raising professionals to track all of the unique information they need about their wonderful work cultivating and stewarding donors, right? Then would someone please explain this to me? Consider this scenario:

"D" is for development database

Sandy: "Why do you only have 3 Fund records in the database? Don't you raise money for more than just 3 reasons?"

Development director:"We're only allowed to have 3 Funds because that's the way the business office needs to see it."

Sandy:"Really? Did they consult with you about how to set-up their General Ledger?????"


AARRRRGGGG!!! This is a real hot button issue for me, and I can't count the number of times I've heard it over the last 10+ years. Don't get me wrong; I certainly welcome and understand the importance of input from the folks on the financial side of the house, (I consult and train on the Financial Edge, too), but the Raiser's Edge is first and foremost a development database. It should be structured toward helping fund raisers track the effectiveness of their fund raising efforts (Campaigns, Funds and Appeals), their stalwart efforts in cultivation and stewardship, and ultimately their successes in securing gifts. It is not an accounting product.

That having been said, what can we do about this apparent conflict? No worries! The Raiser's Edge is a robust  product with powerful reporting tools. If the business office needs to see certain information related to gifts and giving, chances are very good that the system can accommodate their needs. Before you relinquish control of your database structure to the accounting department, make sure that you are fully utilizing all of the reporting tools the Raiser's Edge offers and that you've maximized the potential of your Campaign, Fund, and Appeal records. It is highly likely that we can give your development professionals the information they need AND provide accurate, clean information to the accounting side of the house, too.Often times, if I can sit down with a Director of Development and a CFO for a frank conversation about who needs what and why, we can carve out a beautiful solution that makes everybody happy. Many times, I'm able to point out unused features of the Raiser's Edge that can hep bridge the gap between the two. Occasionally, we're unable to use the standard tools in the system to generate reports for the business office, but that's why you have Crystal Reports.

Has the business office hijacked your development database?

ABC’s of the Raiser’s Edge:”C” is for Constitutent Code

The ABC's of the Raiser's Edge

Constituent code…….I love alliteration, don't you? I love Constituent Codes, too, because

when used properly in the Raiser's Edge, they can tell me alot about why a particular person or organization has a record in your database in the first place.  Is this person on your board? Is she a volunteer? Is he an alumni? Is this organization another non-profit? Is it a grantor? A civic group? A corporate sponsor? Constituent Codes should tell me this kind of information, so that when I, or anyone else for that matter, look at the record, I have a frame of reference for the significance of this person's or organization's relationship to your non-profit. Constituent Codes give me a place to start in understanding your sphere of supporters.




Constituent Codes are set-up in Configuration as a table value

and are entered on the Bio2/Org2 tab of the Constituent Record.


 I've seen both ends of the extreme when it comes to my clients' uses of Constituent Codes in their Raiser's Edge databases. I've seen organizations who don't use them at all (broken heart heart weeping here). I've also seen organizations that used Individual or Organization as the only choices (crying more weeping).  On the other hand, I've also seen organizations who so over used them as to render them useless. I've seen a database with 188 Constituent Codes! broken heart(By the way, after I consulted with them and cleaned-up their database, we ended up with 21-a much more meaningful, manageable number.cheeky)

Broadly, Constituent Codes should be used to define why that record is in your Raiser's Edge database and to help define that constituent's relationship to your organization. In a general sense, they should be used for big picture information that is more long term in nature. Details and short term information should be tracked as Attributes. Like Attributes, Constituent Codes are also useful for identifying groups that you often like to report on or group on. They are available as filters in many reports and mail functions, often eliminating the need for a query.


So, thinking big picture here, Is it helpful to know that someone is on your board or volunteers? Of course it is! Do we really care, however, in 2010, that she played in the 1994 golf tournament??? Really? REALLY? I think not! What do you think?

The ABC’s of the Raiser’s Edge-“B” is for Blank

The ABC's of the Raiser's Edge


"B" is for Blank

When I talk about the beauty of the  Blank query operator in the Raiser's Edge, it often draws a blank stare. Why

should you care if a field is <blank>? Humm…..let's think about that for a minute.When a field is<blank> in a database, that means there's nothing in that field. In database lingo (which I try to avoid when I'm training), it means it "has no value". So, just as an example, if you wanted to identify all of your non-donors in the Raiser's Edge, couldn't you create Constituent query with criteria of Gift Date <blank>? After all, Gift Date is a required field, which means all Gift records must have a value in that field. The Gift Date field cannot be <blank>. Of course, you have a standard report in the Raiser's Edge that would identify those Constituents and create a query for you, but what if you wanted to know who had not given and had never been asked to give, based on Assigned Appeal <blank>? Maybe they've never given because you've never asked them to give! Wow, that would be good to know, wouldn't it?


So, let's add it all up:                                                                                           

A required field               


+ <blank> operator

=no records of that type exist  


     Some examples of required fields in a standard version of the Raiser's Edge

 (your database may have more) include:

  • Spouse records
    • Last name
  • Gift records
    • Gift date                                        
    • Gift type
    • Gift amount
    • Fund
  •  Action records
    • Constituent name (on a Constituent Action record)
    • Action date

So, if you queried on any of these fields with a <blank> operator in a Constituent query, you'd end up with a group of Constituents who don't have that type of information on their records (i.e. no Spouse or no Gifts or no Actions).  

This is a terrific example of using what you do  know in the Raiser's Edge (which fields are required) to figure out what you don't know (which records don't have that information on them). Tons of opportunities to apply this concept in the Raiser's Edge are out there if you think about it. Knowing what's not there can be just as meaningful as knowing what is there! What might you missing by not knowing what's not there?

ABC’s of the Raiser’s Edge:”A” is for Attributes

The ABC's of the Raiser's Edge

All record types in the Raiser’s Edge can have attributes associated with them. Atrributes are customizable by database and are originally set-up in Configuration. I get a lot of questions about (and perform a lot of clean-up of!)


  • What are they?
  • Should we use them?
  •   Do we need them?
  • Why would we use them?
  • How could we use them?
  • What do they do?
  •  What do they mean?
  •  Do we have to?


 Attributes are one of the most potentially powerful customization features in the Raiser’s Edge. That having been said, they are also one of the most abused and overlooked. In my 10+ years of experience, I’ve seen both feast and famine! I’ve seen databases so flooded with them as to render them useless; I’ve also seen them so overlooked as to render the database dehydrated.  In general, attributes are designed to do one of two things, if not both. 

  • To give organizations a place to store information that doesn’t already have a home in the system
  • To track information that an organization often likes to group on for mailings or reports  

In the first case, would it make sense to have a built-in field in the Raiser’s Edge called “Favorite Girl Scout Cookie” with a drop down table listing all the flavors of Girl Scout cookies? Of course not! Would a zoo care about that information? Maybe, but not likely. To my Girl Scout Councils, however, that is very meaningful information, so they track that as a Constituent Attribute with a customized table of choices.

In the second scenario, wouldn’t it be nice to be able to quickly send an email to all of Finance Committee members announcing a location change for their next meeting? If you are tracking Committee Assignments as an attribute, it’s easy as pie. All of the report parameters and mail parameter sets in the Raiser’s Edge have the option to include (or exclude) records in that report or mailing based on Attributes. They are also easily queried on for use elsewhere.

These are just two, very basic examples of how Attributes can be used to harness the awesome power of the Raiser’s Edge and help you work more efficiently. I can think of 100’s more; can you?

1.866.463.3575 Tollfree