Primary Fundraiser Query Error - or User Error?

Beth Dunning

When writing a query to pull the primary fundraiser, I would expect RE to pull the *current* fundraiser, if previous relationship(s) exist.  That is not the result I got.  In (some) instances where a constituent was transferred to another fundraiser, the previous (end-dated) fundraiser was the name displayed in my output.  If this isn't considered a flaw in the software, is this a flaw in my practices?  In addition to end-dating the relationship with a fundraiser, is it expected that I will either delete the role or, at a minimum, select a different role (such as "former primary fundraiser")?  Or am I simply overlooking something in the query tool that would help RE make the distinction between previous and current fundraisers?

JoAnn Strommen

You should be able to pull primary if you add to your criteria something like 'date to' is blank.  Those end dates are key - glad to see you entered for previous person.


Pulling primary in export is even more fun as you must pull at least 2 primary fundraiser and sort asc to get the current primary. 


Yes, it would be nice if RE could just pull.  I don't want to have to go in and change types to be former primary fundraiser. Way too much to deal with. Date to should be enough for RE to pull desired list. 

Karen Diener 2

It might help to keep in mind that Raiser's Edge does not have a concept of "primary fundraiser" in the same way that Primary Business, Primary Constituent Code, or Primary Alumni work.  Although you are using the webview language of "fundraiser", I think you are pulling this in database view where the role is known as a solicitor.


If you are including solicitor name in your query output, also keep in mind that query is a rubber-banding or grouping tool, and not a reporting tool.  Solicitor is a "one to many" field also - you can have multiple solicitors on a single constituent record, and all further defined by their solicitor type and date ranges.  In query, you cannot define which solicitor type you want in the output.


I've worked at organizations that had multiple active solicitors - usually a mix of staff and board/committee member.  Usually you will need to use the Export tool when you want to see a constituent's solicitor.

Brian Davies

So I wrestled with this for a long time. At one Org I worked at we always put a date to of 1/1/2099 for the primary fundraiser, then you could always query on this. At my current Org we left date to blank and queried on date to equals blank which worked in queries, but not so well in exports. I have since changed up my fundraiser types so that it works better in query and export, this also works well in NXT lists. I will worn you, although my solution got better outputs is more work to manage.


I have the following fundraiser types:

Primary Relationship Manger

Staff Solicitor

Volunteer Solicitor

Stewardship Manager

Spouse Solicitor

Former Primary Relationship Manger

Former Staff Solicitor

Former Volunteer Solicitor

Former Stewardship Manager

Former Spouse Solicitor


When a solicitor assignment is made I assign "Primary Relationship Manger" to the constituent with a start date. (and campaign if appropriate) If the spouse has a full constituent record then I assign "Spouse Solicitor" to the spouse. (this is needed for use in case a gift comes in from the spouse we want to make sure we can credit the right solicitor without having to crosscheck) When an assignment changes or ends I change the current Primary Relationship Manager to "Former Primary Relationship Manager" and add an end date, then change the spouse to "Former Spouse Solicitor" with an end date. Once this is complete I go back and assign a new Primary Relationship Manager.


In this way you can always query solicitor type equals "Primary Relationship Manager" and in Export you can list the export output as "Primary Relationship Manager" This make for a clean and easy export, query or list as long as you keep your data clean.

Beth Dunning

Thank you for your insights.  You each offered a helpful perspective on the problem I encountered.  But the explanation (or reminder) about the one-to-many fields in Export was the biggest "aha" in understanding the root of my problem.

Much obliged.