All posts by David Zeidman

Moving over to SKY API

This blog has mainly consisted of the COM based RE7 API and my musings of all things Blackbaud related. I am sure that the latter will no doubt continue but I have realised for a while now that as time goes on the RE7 API is becoming less and less relevant (although not entirely so) and that there is a natural progression towards the SKY API.

In general there is probably less to be said about SKY API. Firstly Blackbaud have been doing a much better job at documenting it than they ever did with the RE7 API. They are also putting a lot more thought into it so that there are far fewer inconsistencies (so far at least) than there ever were with the RE7 API. Where there are difficult, new, areas they have written up good documentation or blog posts to explain. In short they have made my job here somewhat redundant… Well thanks a lot Blackbaud!

Actually, yes, thank you. I would much rather a clean usable API than one where I have to write up blog posts explaining how to do things. I am sure that there will be moments but there will quite possibly be fewer of them.

One topic that I think deserves some discussion though is the porting of existing functionality from RE7 to SKY. Those of us that have products written for RE7 are keen to see the functionality available on SKY in order that we can port the solutions over.

I have been very keen to transfer Chimpegration but one of the stumbling blocks has been the lack of bulk data processing on SKY. Specifically the ability to return filtered lists of constituents. On many platforms this means simply specifying a last data changed or a keyword search. On RE7 though it is possible to make use of a query to retrieve that information. The user would themselves set up the criteria in the query and the application would allow the user to select that query.

There is some discussion on the SKY API forums about how imperative it is that this be ported over to SKY and that we should be allowed to once again select an existing query.

Despite really needing this functionality for Chimpegration, I am not convinced that this is the best course of action for SKY. This new API should embrace a general approach to this problem. It cannot be based on RE7’s query module. There is definitely a need to generate lists based on complex filters and criteria and that should be exposed somehow to the developer community but to simply port the existing RE7 functionality to SKY would be short-sighted and not take into consideration the other applications what will one day make use of the same API. I want an API that will work with RE, BBCRM, ETap and others. To simply port queries to SKY would confuse the issue and make for an API that is not consistent.

What does Blackbaud buying JustGiving mean for the nonprofit world?

If you have not heard, Blackbaud just bought JustGiving for £95m ($123m USD) pending regulatory approval. If you are not familiar with JustGiving then you are clearly not based in the UK. JustGiving is synonymous in Britain with peer to peer fundraising. Every marathon, swimathon, cycle ride or mountain trek will invariably lead to sponsorship via JustGiving’s website. This is despite very many charity’s attempts at breaking free from JustGiving’s hold over the donor. The non-profit may try to make use of competitors’ services or encourage supporters to use homemade or white labelled sites but the supporters still return to JustGiving in their droves.

In my mind it is clear what Blackbaud can get out of this purchase. JG have a very large market share in the UK, have a very good reputation among donors and only slightly less so among the non-profit recipients. Their platform is user friendly and customisation and configuration opportunities are relatively advanced compared to their competitors.

What does JustGiving get in return? They have the lion’s share of the UK market. And therein lies the problem. They have tried to break free from the UK for some time but without any great success.

The UK has a special model that JustGiving and others are well placed to take advantage of. GiftAid allows nonprofits to claim a percentage of the donation back as a tax rebate. JG and others take a cut of this reclaimed tax. Away from the UK, the lack of this tax incentive means that JG and others have to compete on fees alone.

This cannot be the only reason for success. After all within one market everybody should be on a level playing field. The Crowdrises and Classys of this world could also take advantage of GiftAid but, so far at least, have yet to do so.

The exporting of financial services to other countries is notoriously difficult. Just look how many international banks you see on your high street. It is understandable that JustGiving would have found it difficult to succeed abroad.

Blackbaud has the expertise in many overseas markets that could help advance JG’s ambition. It has much deeper pockets which also helps!

In the UK, JG often comes under fire for charging non-profits larger than necessary fees. Whether they genuinely are too large is questionable but perception is everything. Will Blackbaud be able to alter this image? In the past Blackbaud has suffered from this too but, especially in the US, has been able to soften this point of view and is now seen as giving much back to the non-profit community.

How will both companies change because of this? Until regulatory approval has been met,  both organisations will carry on as normal and are not able to give any indication as to the direction their products will take. What is clear is that there is some overlap in products. Everydayhero and Teamraiser both offer similar functionality. Will they both remain alongside JustGiving? How will Blackbaud’s limited JustGiving integration application (BlackbaudLinks) be developed? Or will Blackbaud rely on other more sophisticated applications that bring in JustGiving data such as Importacular?

Our MailChimp API Headache

It has been a while since I last posted on this blog. The main reason is that we have been so very busy for working and struggling with version 3 of MailChimp’s API.

Around two years ago we became aware of MailChimp’s latest API. It was certainly a very good example of a clean REST based API having all the characteristics of a well designed interface. All of the structures made sense and the anybody used to working with REST based APIs would have no difficulty in picking up this new API and creating a new powerful application with it.

So what went wrong?

About 18 months ago MailChimp informed the community of developers that it would be retiring all their other APIs in a year’s time so that they could concentrate on v3 as being the sole API. This meant shutting down not only V2 and older instances but also the export API.

This was a really big deal for us as Chimpegration made solid use of V2 and definitely the export API.  When we first gave MailChimp a demo of Chimpegration they told us that it was one of the most complex and intricate applications making use of their API. They were blown away by the detail available in synchronizing and the level of user choice that made up the application. What is more many of the features that exist today were not available at that time including the synchronization of groups, use of profiles and the ability to remove subscribers based on a query.

The news that MailChimp were going to shut down their API came as a shock to us. It meant some very big changes in Chimpegration without much to show for it. How can you possibly sell the fact that Chimpegration now uses V3 instead of V2. Nobody cares as long as the application carries on working.

What was clear to us when we started working with V3 was that those who designed this new API really had not spoken to anybody else about it. It was as if they had been working in a isolated area of the building, kept away from any V2ers or for that matter, existing users of V2.

They changed the structure of areas of the API such as groups. (The ids of V2 groups no longer match the ids of V3 making it very difficult to transfer to the new version unless we only consider the names of group items rather than the ids). They added a batch method so that you could send very many calls to MailChimp but they had no idea what the maximum allowable would be. We would wait, send through our batch updates and wonder if it would time out or not. They changed the unique identifier for a subscriber so that it had no bearing on the previous unique identifier. This meant that clicking on a link to bring up the contact in MailChimp no longer worked because the unique identifier no longer existed. (This has now been fixed, or at least we are redirected to the correct contact).

One of our biggest headaches which is still ongoing is around segments. The new API made it very difficult for us to look up a subscriber by constituent id (The Raiser’s Edge unique identifier). This, we had always insisted, be stored as a merge variable. Of course if we were starting from scratch we would use the new MailChimp unique identifier and store that in Raiser’s Edge but this would be an enormous change and one that would not work with existing organizations.

Previously we would feed in a segment into the method that would get the subscriber details. This segment would retrieve the subscriber by constituent id. This was removed and with it an enormous stumbling block was put in front of us.

Some relief was forthcoming about a month before the cutoff deadline. MailChimp announced that they would not be shutting down the export API. Clearly it was realised that the batch methods were just not good enough for large data transfers. This was important news for us as we relied heavily on this part of the older API.

It still leaves us with the issue of segments. The V3 developers did not look at the V2 segments. Instead they just changed the format. The problem, or course, is that the export API takes in segments in the V2 format. It is all very well fetching the user’s existing segments and then passing them into the export API (an extremely powerful feature that we have been making regular use out of) but all of a sudden we have to adjust each segment in order to convert it to a version that the export API understands.

What we would like MailChimp to do:

  • Either expose the V2 segment definitions again or allow us to pass in V3 segments into export. Either way should not mean that the existing method is just turned off. We need to time to convert and test.
  • Update the export API so that it is fully compliant with V3 (again keeping the existing calls backward compatible)
  • Produce a guide to transitioning from v2 to v3. I have been asking for this since we started and amazed that this was never forthcoming.

 

To our Raiser’s Edge Chimpegration customers: thank you for your patience. We realise that you do not care who is to blame for issues with Chimpegration as long as the application works. We understand that and, as ever, strive to release fixes to issues as soon as we are told about them. After much work we hope that we have reached a point where this latest version of Chimpegration is now more stable than ever. We continue to work on the plug-in to ensure it remains as useful as possible in integrating these two great applications.

Importacular Arrives on Blackbaud Hosting

When we released Importacular almost a year ago we broke the mould in how Raiser’s Edge importing tools worked.

Before that time it was:

  1. Export the data Eventbrite/Crowdrise/Classy/JustGiving/etc  ensuring that you export only the data you need from the last time you ran the process
  2. Try to remember where you saved the file
  3. Pick up the file
  4. Map the values from one very long list of Raiser’s Edge fields
  5. Import the data (fingers crossed)
  6. Map a second time to do another pass because not everything can be imported in one go.
  7. Panic because you still have to justify cost to your boss / the board

With Importacular:

  1. Pick the data source Eventbrite/Crowdrise/Classy/JustGiving/etc
  2. Set up your mapping conveniently split up into areas making importing constituents, relationships, relationships of those relationships, education records of those constituents with gifts (actually any number of layers of constituent relationships with their child records) surprisingly easy
  3. Import the data (once)
  4. Tell the board how you are going to spend all the extra money that you saved

The first year was a whirlwind.

It started with Eventbrite and Graduway, moved on to Hubspot, Constant Contact, Formstack, SurveyMonkey, Justgiving, WeDidIt, VineUp, Crowdrise and most recently DotMailer, Adestra, Classy, iSAMS and to come Almabase. (We shouldn’t forget the humble CSV and Excel file too)

With the ability to import on to constituent records and gift records entirely for free, we added relationships, education, actions, banks and financial accounts, participants, prospects and proposals, solicitors/canvassers and volunteers.

When we added the ability to schedule imports that left one gaping hole in the product that was ready to be filled.

When would it be available for Blackbaud hosted organisations and those that wish to move to NXT?

It took a while but we are really excited that Importacular is now available to all Raiser’s Edge users wherever they work.

If you would like to try an import then get in contact. Even if you are using another product give Importacular a go. It is, after all free to import on to constituents and gifts so what do you have to lose?

If you are hosted by blackbaud then request a trial

If you are self-hosted go ahead and download Importacular and get started for free:

My BBCon 2016 Sessions to Watch Out For

BBCon 2016 (Blackbaud Conference for Nonprofits) is soon here. We are back in Washington DC again this year and whether you are a first timer or a regular, you will surely be as overwhelmed as I was by the choice of content available. That is why, once again, I have sifted through the breakout sessions looking for my top tips.

As you may have noted there is one session less in my list this year. I won’t be speaking formally at any breakout session but all is not lost. I shall be at BBCon so if you would like to hear me speak, just approach me and either hover creepily beside me listening to my dulcet English tones or (somewhat more appealingly) engage me in conversation.

Anyway enough gratuitous self-promotion and on with my list of sessions.

My choices are split into two concise categories and one less than concise:

a) Sessions whose speakers are amazing

b) Sessions that talk about software development and NXT development

c) Sessions that probably have amazing speakers but what really bought it for me was the description (because I cannot remember having heard the speakers before).

Raiser’s Edge NXT: Moving to and Mastering the Next Generation of RE

I always recommend Bill (and not just because he acknowledges me in his book Fundraising with The Raiser’s Edge). He is always a joy to listen to. He not only has an in depth knowledge of Raiser’s Edge 7 and NXT but his ability to convey that information in an interesting and thought provoking way sets him aside from everyone else who works with these products.

Moving forward to meet your growing needs: a solution discussion for Large Raiser’s Edge 7 customers

Other than Jim who I have heard speak, I cannot say that I have heard these speakers before. However this is such a recurring issue among our clients that it is definitely worth addressing the challenges and solutions faced by large organisations.  I would be very interested to hear how NXT, Luminate CRM and BBCRM overcome the limitations that RE7 has faced for larger organisations. I am looking to hear about;

  • how processes have been automated because it is just not practical to enter data manually
  • how systems can be integrated because larger organizations typically do not only have systems from one company
  • and also how organizations can better utilize their volume of data to analyze their fundraising performance.

 

Raiser’s Edge NXT Roadmap

This is always a must. The fact that there is no Raiser’s Edge 7 roadmap is, of course telling that the focus is and always was going to be on NXT. (That being said I do hope to hear about any snippets of information about RE7 – not everybody is ready to move just yet and much of NXT life is still lived through the eyes of a hosted RE7 instance).  The roadmap sessions are often the ones that swing it for Blackbaud. People will go away feeling either elated or underwhelmed. Let’s hope the former.

Bill and Ed’s Excellent Adventure in Raiser’s Edge

I have already sung Bill’s praises but if Bill ever had any competition then it was from Ed. Back in the day of the RE Geeks, I often felt as though I were in the shadow of Bill and Ed whose combined tower of knowledge and eloquence put my own expertise to shame. Aside from the speakers it is also good to have a session format that is a little more informal than many other sessions. The demonstration and discussion format (the demonscussion?) really does work when covering more complex topics requires clear visual aids and clarification.

Integration with Blackbaud SKY API and SKY UX

Build an app using SKY UX and SKY API

I have grouped these two session together because they clearly have a lot of overlap. I can only assume that integration refers to connecting with other systems whereas building an app is enhancing the existing application. Maybe the order of SKY API and SKY UX will also have some bearing on the emphasis each places within their sessions.

I have only heard Dan speak (Integration) at previous sessions and indeed have worked with him during the API discovery process. If his session is anything to go by his past performance then this will surely be a very interesting session. There is so much that can already be done with the Sky API and the team have only just touched the surface. I am excited to see what they have produced in these sessions. Who knows they may even demonstrate our own SKY API Chimpegration product! Now that would definitely be worth viewing.

Working with RE7.95 and phone configuration rules

In v7.95 of RE7, there were some new config business rules introduced which prevent duplicate phone or emails being added to a record.

phone config

I have not really found this to be consistent though. When I use this inside of a constituent record it does not seem to make the slightest difference which setting. I can have to “Email” phone types but no matter which setting is selected above it saves fine. This does seem to work better with phones (as opposed to emails). Although even when I have the setting as “Do not allow record to be saved” it still prompts to if I want to save it.

When I run this through code however I do get an error… sometimes.

If I have a matching phone type but different phone number it seems to work fine most of the time (although once I got an error message). If I have a matching phone type and phone number I will always get the error as shown below. This does not seem to be affected by the options above though.

duplicate phone error

I am wondering wondering if there is a way of controlling the error. If this were working as expected then it should be possible to permit the record to be saved if the options is “Display warning”.

Here is my test code:

 Public Sub TestSavingDuplicatePhones()
 
        Dim constit As New CRecord
        constit.Init SessionContext             

        constit.LoadByField uf_Record_CONSTITUENT_ID, "3"
        
        Dim parent As IBBPhonesParent
        Set parent = constit        

        Dim phone As CConstitPhone
        Dim phones As CConstitPhones
        Dim dataObj As IBBDataObject
        Dim phone2 As CConstitPhone
        Dim dataObj2 As IBBDataObject
       
        For Each phone In parent.phones
            Set dataObj = phone
            If dataObj.Fields(ECONSTITPHONEFIELDS.CONSTIT_PHONES_fld_PHONETYPE) = "Email" Then
                Set phones = parent.phones
                Set phone = phones.Add
                Set dataObj2 = phone
                dataObj2.Fields(ECONSTITPHONEFIELDS.CONSTIT_PHONES_fld_NUM) = "1234"
                dataObj2.Fields(ECONSTITPHONEFIELDS.CONSTIT_PHONES_fld_PHONETYPE) = "Email"                             

                Exit For
            End If
        Next       

        constit.Save        
        constit.Closedown
        Set constit = Nothing   
   End Sub

What is the difference between Chimpegration and Online Express?

What is the difference between Chimpegration and Online Express?

We are big Blackbaud fans and love much of what Blackbaud produces. Online Express is no exception. The fact that there is one application that can ask for donations, handle event registrations, manage memberships as well as allowing you to send out targeted and personalised emails is amazing. What is even better is that it does so with a complete integration into The Raiser’s Edge. – WOW!

Continue reading What is the difference between Chimpegration and Online Express?

Just When You Thought Validatrix Could Not Get More Complicated…

One of the problems of offering a tool that can create custom business rules for almost any scenario is that it has to have a lot of functionality. As we developed Validatrix we realised that some of that functionality was missing so we added it on. The problem with that of course is that the more you add on the more complicated the application becomes.

We have attempted to remedy this by offering the Validatrix Query Converter which does a good job of converting queries into rules and is often a good starting point for expanding a rule further.

We realised that we had missed out on a piece of functionality that was preventing us from creating a rule with a specific scenario. It is possible to all sorts of logic within one rule. We can check if a field value is exactly the same as another, if it is not the same as if it is greater than or less than etc. Continue reading Just When You Thought Validatrix Could Not Get More Complicated…

Chimpegration on Blackbaud Hosted Raiser’s Edge (and NXT)

I cannot think how many times I have had to write back to a prospective client with the stock phrase “Unfortunately our products are not available on the Blackbaud hosted environment at the current time”.  The ground-breaking news is that after at least 7 years waiting in the wings, we are able to release one of our products on the Blackbaud hosted environment. (Finally I can updated my stock phrase)

When it was first released Chimpegration revolutionised the meaning of integration within The Raiser’s Edge world. It was the first app to fully embrace the potential of two separate platforms to transfer data between Raiser’s Edge and MailChimp. Unlike some integration applications it takes data directly from the source. Data flows from MailChimp via Chimpegration into The Raiser’ s Edge and back again. There is no need for any manual manipulation along the way. Chimpegration gives you a multitude of options to help smooth the different data points and ease the transition of information from MailChimp, an email marketing suite, to The Raiser’s Edge and donor management CRM system.

Azadi Sheridan, independent fundraising data expert, RE guru and former Blackbaud senior manager said,

‘Integration’ can mean different things for different products, but Chimpegration is the most complete and automated integration for MailChimp that I’ve seen for any fundraising database.

And now all of this is available to Blackbaud hosted clients too!

What does this mean for the future? One of the issues that many of the prospective clients faced and even our existing clients was whether they should invest in technology that is not available to them on NXT. They would put off a purchase or renewal decision because they wanted to wait and see what NXT would hold. RE7 has so much functionality but NXT looks amazing.  Having the best of both worlds is certainly a selling point for any organisation. With Chimpegration on the NXT hosted platform it is easier than ever to transition across to NXT and keep working with MailChimp.

So now you have heard all about it why not request a demo of Chimpegration.

Ready to take the plunge? Request a trial of Chimpegration on hosted.

If you are not hosted and have questions please get in contact too. Those who are not hosted by Blackbaud can also download and trial the Pro version of Chimpegration now from our Chimpegration page.

Validatrix Query Converter Makes it even easier to protect your data

When we first developed Validatrix we had a lofty ambition that users of Raiser’s Edge would be able to protect their records using any combination of business rules. Out of the box, RE allows you to make some fields required. If the whole organisation wants city to be a required field all you have to do is going to configuration and set that field to be required.

However there are many limitations with that. What if we are only working with email only records. We may not have a physical address for those constituents. Validatrix makes it possible to combine criteria to validate records.

(Do they have an address block: YES
OR
Do they have an a postal code: YES)
SO
DO they have a city:

No? Well show a message.

What we soon realised was that for simple scenarios it was not that difficult to create rules. We also realised that after much practise and taking a look at our Validatrix Recipes area on ZeidZone, it became easier. Those starting out or writing more complicate rules needed a little more help.

That is why we developed the Validatrix Query Converter. Most, if not all DBAs can write a regular RE query. If they can write a query to give all the records where a message would be shown then this tool can convert the query into a Validatrix rule.

I have to say straight up here that not every single scenario is covered. There are some things (not many) that query can do that cannot be done in a rule. (There are so very many more things that Validatrix rules can do that query can do!). However this should get the beginner and those that are working with complex rules onto the right track.

If you have any questions about this product then please do not hesitate to get in touch with us here.