Using The Raiser’s Edge and Salesforce in Peace and Harmony
Pop-quiz; please close out of Facebook and answer the following question:
‘If I use both The Raiser’s Edge and Salesforce to manage different areas of my nonprofit, it’s because:
- I’m freakin’ crazy
- I truly enjoy working way too hard
- I’ll soon be dumping one system in favor of the other
- I realize that I can both engage more constituents across the board and raise more money by leveraging the best data out of both systems
- I’ve started to ‘drink the Kool-Aid’ – and think just maybe that RE and SF could peaceably co-exist
The correct answer, of course, is ‘d’, and there is certainly hope for those who selected ‘e’ and have an open mind about RE and SF working collaboratively in peace and harmony.
Omatic Software has worked with a number of clients who haved decided to effectively use both RE and SF to each systems’ advantage, and we are getting more and more inquiries each month from clients who are using both–or contemplating using both–systems. The key is proper configuration of both databases, which is needed to support the effective exchange of key data back and forth.
It goes without saying that nonprofits love RE as a development-focused CRM system – one could debate that there is really nothing that compares with RE (‘regular’ ‘Classic’? or NXT) for managing fundraising-related engagement, donors, prospects, transactions, and activities.
In the same vein, SF can be built out to very effectively serve non-profits’ non-fundraising system requirements – with great facility to support complex sales, marketing, ticketing, case management, program management, and related organizational needs.
Nonprofit strategists will immediately recognize that data in each system could be very effectively leveraged by the other, assuming that the systems can effectively talk to each other and assuming that someone is watching out for which data are exchanged between the two.
One quick example, and then on to the tactical stuff: Omatic recently worked with a client that used RE for fundraising and SF for program management. The programming revolved around connecting individuals into community-based discussion groups, which would then meet regularly to focus on advancing the mission of the organization in their community. The organization used RE for traditional fundraising and SF for marketing the discussion groups to engaged and unengaged individuals and then tracking the individuals’ group membership and participation. It was obvious that those engaged in discussion groups would be prime fundraising prospects; similarly, those who donated to the organization because they wanted to support the mission overall might be great prospects for discussion groups.
The major challenge was how to easily and systematically exchange the right data back and forth, and ensuring that it was properly coded on both sides. The solution was Omatic’s ImportOmatic Connector for Salesforce, which addressed those challenges effortlessly and comprehensively.
The example discussed above is one of many – but in working with organizations that use both RE and SF, Omatic has picked up some key learnings that we want to share. Below are some things to consider if your organization uses both RE and SF, and wants to leverage the potential value of integrating each systems’ key data with the other.
1. Which system is the organization’s System of Record – which system, for example, will be the first place to enter biographical updates – changes to geographical addresses, phone numbers, email addresses. The system of record will most likely be the system with the most current information.
2. Is there consistent record structure between RE and SF. Typically, RE Constituents = SF Accounts and RE Relationships = SF Contacts. Is Householding treated consistently in both systems?
3. Which data need to flow between systems – and especially, which data live in one system that do not ‘naturally occur’ in the other. Will you be focusing on individuals only or organizational data as well? Does transactional data need to be exchanged, and how will source transactions be coded in the destination system?
4. Is it worthwhile to audit both systems in advance, to ensure that the envisioned data flow will work (We generally think ‘yes!’). Will RE attributes or custom SF fields need to be configured? What new coding needs to be designed and configured to support the ‘foreign’ data that will now be coming in regularly? Are there any business rules that need to be incorporated (eg, the constituent ID for any new constituent that comes into RE from SF will be appended with an ‘S’)?
5. Process definition: Will data be traveling both ways or just one way? How frequently do data need to be exchanged? How do you want to address duplicates? How will you address biographical dissonance (eg, same constituent, different email address)? What is the method for adding new data elements to (or subtracting them from) the sync as the process evolves?
Lucky for you Omatic Software and Heller Consulting are experts in world on non-profit database technology, systems integrations, and – in particular – working with both RE and SF. If you answered ‘d’ or even ‘e’ to the pop quiz, then you are a visionary; please let us know if we can help you achieve your vision. If you answered ‘c’, we hope you’ll reconsider, but we probably can help you with the transition if we can’t talk you into the power of integrating two best of breed solutions. Now, if you answered ‘a’ or ‘b’, there are some therapists that we can recommend . . .