Towards the end of 2010 we started working with Potentiality to integrate their system with The Raiser’s Edge. At the time I knew very little about them and their products. Their headquarters is in Melbourne, Australia with an office in London. Even though they have an office in London our main contact was with their Melbourne office. Their product was a community based content management system (CMS) targeted towards schools and universities but also used by any organisation that was trying to build up a community of supporters.
When Potentiality first approached us about working with them they already had links to other database applications. They had a framework for determining duplicate records and allowing their end users to process data that had been imported into the system from other applications. Their goal was, of course, to reuse as much of this as they could rather than getting us to develop this area. We would start simply by synchronising constituent data with a view to extending the integration in the future. Their existing method of data transfer was through XML representing the data structure of an individual. Since this was their first exposure to The Raiser’s Edge I explained the difficulties that implementing a generic solution would face. In their other database implementations there were fields that simply did not exist natively in RE. For example there is no next of kin field. That does not mean that an organisation has not created an attribute of “Next of Kin” in order to store that piece of information but it could also mean that a different organisation stored it elsewhere or did not store it at all. We streamlined the process to only include fields that were native to RE.
Of course another difference that RE has with other database implementations is the fact that there are no fixed phone or email types. One implementation can use “email”, another “e-mail”, a third “Personal email” and “Business Email” or a combination of all of these types. What is more there is no definition of a primary email or phone type. We needed to evaluate this type of issue (along with a host of other issues) to see how the integration would handle the difference in paradigms.
Integration is such a small part of the application. Potentiality’s solution is so much more. The community that can be generated by bringing together the organisation’s supporters through events, gallery, business directory many other areas makes Potentiality shine among many such solutions. One thing that impressed us was the way that it embraced other social media communities. Many CMS community solutions see the popular social media sites like Facebook, LinkedIn and Twitter as a threat to their solution. Rather than seeing a threat, Potentiality have developed integrations themselves with these platforms so that end users don’t need to choose one over the other but can embrace them all with the biggest winner being the community.
The integration that we helped develop ensures that the data moves from the end user through the community and onwards into The Raiser’s Edge. Without the data integration there is a discontinuity between what the end user knows and can contribute and what the organisation can ever hope know about its community members. While our integration was a small part of the overall solution it plays an important part for those organisations that make use of both Potentiality and The Raiser’s Edge.