Running two non-profit orgs from Raiser's Edge?

Tom Klimchak

Hi...


Our school is partnering with another 501(c)(3) and they've requested that we take over the fundraising of the second organization and keep all the data separate from our own data.


I can see how we could keep gifts separated out with Campaign and Fund codes, but keeping the Constituents and Actions and everything else apart seems.... a little more challenging.  Even if we keep the gifts apart it means that EVERY single gift report we ever create moving forward will have to keep track of which organization the gift goes to.


I found an old community thread about this and was wondering if anyone else has been doing this lately and would love to hear any recommendations on how to handle this.


Thanks!

Claudia Sauers

I have no experience with this but the only other consideration I could think you might have is either a constituent code or attribute that designates which organization the record belongs to. At first thought I would even think having separate records for each person and each org might be an idea for example Bob Smith Org A and Bob Smith Org B as separate records as a secondary measure to keeping your gifts/actions/etc. separate, it would however significantly boost your record count. Best of luck, I'd love to hear how you end up proceeding.

Brian Davies

Will you have donors who give to both organizations?


My first thought is constituent codes are the way to go, but by adding a constituent attribute with the org(s) that the constituent is affiliated with might work better since you can easily use the include/exclude functionality already built into most reports. It would be easy enough to write into queries as well. The other option of course is to have the orgs each have their own database.

JoAnn Strommen

As stated in the old thread, we still continue to track records of the main Y and two branch YMCA's. We use constituent codes and it has worked well for us. 


Attributes should work too. As I posted back then you may want the attribute on all records and make it required to keep it clean.

Gracie Schild

At my previous job, the Foundation raising money for the College just got its 501c3 status and started accepting donations about 6 months after I started, so I was in on the entire set-up. The College had been accepting and recording gifts in RE and posting to FE. Since the Foundation was taking over the database and all the donors, we used a method suggested by the divine Ed Hohlbein: A new set of Fund numbers for all Foundation gifts. We were using 4 digit fund numbers and we simply started at 8000 (well above the existing range of fund numbers) and recorded gifts on the same constituent records. That way we had the long-term giving history intact and only had to do some creative reporting for campaigns or funds that crossed fiscal years. I ran a bunch of reports to transfer the gifts (usually monthly) to the College. Once the transfer was approved by the Foundation Board, gifts to the College's corresponding Funds (5001 in the College matched 8001 in the Foundation, for example) from the Foundation were recorded in the same instance of RE and those gifts were reconciled against FE. The detail of who gave what was all on the Foundation's side of RE, and the College's Finance Office only had the totals applied to the different funds. Worked like a charm!


If you're merging databases, then you need to convert one system of funds and so on to the other, and I do think it would be helpful to have an Attribute of the source database for each constituent. If you're running parallel 501c3s in one instance of RE, I'd say do something like our trick above. You could put an identifying number or letter in front of whatever form of Fund ID you have, and perhaps make different campaigns that are the default for funds belonging to that organization - anything to make it easy to keep separate and sort.


Gracie

F O 2

Brian Davies:

Will you have donors who give to both organizations?


My first thought is constituent codes are the way to go, but by adding a constituent attribute with the org(s) that the constituent is affiliated with might work better since you can easily use the include/exclude functionality already built into most reports. It would be easy enough to write into queries as well. The other option of course is to have the orgs each have their own database.

This was the solution where I work..in addition to the main database, there are two other databases under our account for smaller rural foundations. When logging into RE I get the option to choose which database I want to log into.

Kimberly Howes

We track 6 separate entities in our database and pull reports at the fund-level. Each fund has a 2-3 character pre-fix that is reflective of the organization's name and we re-purposed the 'Category' field to record the 'Entity' tied to that fund. We then set-up a fund query for each 'entity' to pull together all of the funds for the particular entity for reporting. From a constituent perspective, while we don't track that in our system since many of our donors give to several or all of our entities, you can use a constituent ID prefix or suffix to identify the affiliation and/or use a constituent attribute. 


There are certainly challenges with tracking multiple entities in one DB, but it can be done. Happy to chat with you if you have questions.


Kim

Neil Scarse 2

This is precisely the situation we're in (3 separate datasets in the one instance of RE).  Yes, we have separate fund ids, etc., as well as constituent codes that assign that constituent to one or more affinities.  However, the problems are worse than that, particularly when a supporter is a supporter of more than one affinity - e.g. an alumni, but also a donor to one of the other charities.  Because we're talking 3 legally separate entities in theory every piece of information should be attached to one organisation.  For example, just because a donor has given consent to one organisation to email them, doesn't mean they've given it to the others; so organisation specific phone (email) types is a must.  If a supporter provides their new address to one organisation, it can't be assumed they are happy for the other organisation to also have it and use it, so you're probably needing to have difference address types.  Going further, what about notes, media items, actions, etc.?  And what happens when you are no longer responsible for the data and you need to separate the data back out and hand it over?!  This is something that happened to us in the recent past (we used to manage 4 legally separate datasets), and it took a huge amount of effort, not to mentioning manually reviewing 1,000s of records to ensure we weren't providing the organisation with data that wasn't theirs ... which would, of course, have constituted a data breach.  You also need to consider security so that only those that need access to an organisation's data has access.  Quite tricky in RE7 for those who have a relationship with more than one organisation.  As Brian floated, I'd err on the side of separate databases, or as close to that as you can get.  Good luck.

 

Gwen CapersSingleton

If you run both orgs from same RE db, seems like org-specific constituent codes, campaign/fund accounts, and letter codes would allow you to isolate constituent records and gifts for queries, reporting, and pulling org specific acknowledgement letters.

Heather MacKenzie

I hope, Tom Klimchak‍, that you have either discovered or already know about security by constituency in the Admin area?  This can help keep non-supervisor users from seeing the records you don't want them to see in case that's an issue here as well as distinguishing the date itself.

Tom Klimchak

Yep! There are lots of ways to "sort of" separate out constituents and even gifts from one class or another, but that then leads to much more complex reports (each one has to have multiple filters to grab only a small subset of data) and we still run into issues where one constituent is shared by both organizations.  


And, honestly, we've already had issues with our Development Officers looking at data in NXT and accidentally including things they shouldn't.  


We're opting for two completely separate instances/databases of Raiser's Edge.... It's so much cleaner and easier to work that way, and there could be a time years from now when the organization will want to completely separate from us and they will already "own" all their own data.