Last week I have been working for MAF Norge to connect CiviCRM to their SMS Gateway (PsWinCom) so that they can send and receive SMS from within CiviCRM. In addition PsWinCom offered a the possibility to send SMS which will charge the receiver an amount of money. This way MAF Norge used to receive SMS donations. Now they can do that from within CiviCRM.
SMS Autoreply extension
The SMS Autoreply extension does sends auto replies to incoming sms-es. It is triggered by a keyword...Read more
A final blog about our Donor Journey sprint with Steinar and Helen from MAF Norge. Or I should really say our sprint on CiviCRM Trigger Action. We set out to at least create the first basic version of the engine to automatically do stuff based on stuff in CiviCRM :-) Some kind of mechanism that would allow MAF Norge to automatically move donors into specific groups once they have contributed for the first time or set up a recurring payment for example. I feel we have made a good really start on the engine, for more technical details read the previous blogposts by Jaap Jansma (jaapjansma in Civispeak). The first test was quite successfull, and going through the list of triggers with Steinar worked pretty well. As we expected we did make one of the most unsexy things ever, which is a nightmare to configure. So even though Helen and Steinar can work with it, it is not something I would hesitate to hand out to everyone...but it is...Read more
Today a new blog post about the progress of the implementation of Donor Journeys into CiviCRM. The route we are taking is that we want to create a trigger/action extension for civicrm because most the donor journey automation is based on a trigger/action. e.g. payment coming in resulting in a thank you SMS a day later.
Yesterday and today we have been working on refactoring the extension to meet the requirement of combining multuple triggers and having the possibility to have condition on custom fields as well. So we have decided to let go the trigger action table/structure and have decided that we have a rule_schedule table...Read more
Yesterday I wrote a blog about the first day in the sprint for the donor journeys. I have discussed that we are focussing on a trigger/action extension to automate most of the donor journeys. I wrote a bit about the internal working and the data structure of this extension.
Today we have finsished the internal working of the system. It is now possible to define triggers and actions. Right know you can enter those only in the database. We have made a start with the user interface and we continue to developer the user interface tomorrow. So that a user can enter a set of triggers and actions. In this blog post I want to show you how you can enter the trigger and actions in the database. The reason is that this will show in more depth how the extension works.
To explain how the extension work let me first explain which trigger/action I will use in this example.
Example: add every...Read more
Christmas is long over, yet we have a wish: we want to introduce a new field to `civicrm_contribution`, (tentatively) called `sequence_number`. This will give contributions records belonging to a recurring contribution some self-awareness, by recording which installment in the series each contribution record represents.
Our itch to scratch here regards to direct debits, where we need a simple and reliable method for determining which installemnts have already been created, and which still need to be created. But let's think big: it seems to me that storing this information should be useful for other types of recurring contributions as well.
Note the emphasis on reliable. In the ordinary case, we should be able to derive the sequence number easily by counting the contribution records. However, in the Real World (TM), nothing ever goes as it should -- especially when computers are involved :-)
For one, counting only works if the...Read more
Third webinar can be found on https://www.youtube.com/watch?v=xYkzUgeJMro
Latest news: second webinar can be viewed on https://www.youtube.com/watch?v=2uDAjCM6T5s
First webinar can be viewed on https://www.youtube.com/watch?v=t3iYtUNre7g
In the beginning of the year I wrote a blogpost on Donor Journeys and CiviCRM (https://civicrm.org/blogs/erikhommel/donor-journeys-unconference-and-civicrm). As a first step we have created a specific CiviCRM forum on Fundraising and Donor Journeys (http://forum.civicrm.org/index.php/board,88.0.html). But we are also going to do a first series of webinars on this topic:
- Rupert Tappin of...
Have you ever needed to send an email from CiviCRM that includes a list of upcoming events? Then you know how much fun the copy/paste effort this entails, especially if you want to use a checksum in the links to register. Plus you know you get to repeat the whole exciting process for the next newsletter the following week or month. Or if you have someone else you need to train on this task, try explaining to a non-technical person how to hand-edit the URL query string to include the checksum paramaters. (is the contact ID query string param name "cid=x" or "id=x", well that depends....) And even if you do not deal with events, you can have the same fun teaching someone else to properly use checksums when you need to include a hyperlink to a contribution page or a stand-alone profile.
If you want a much easier process for listing upcoming events with links to register, including links to contribution pages and stand-alone profiles, then try out the new extension...Read more
eWay is an australian payment processor that provides a seamless connection with many banks and allows for recurring payments, token payments etc.
CiviCRM has had a one off payments processor for eWay for a long time, but has lacked one for recurring payments and now it is finally here!
This payment processor has had a long history and there are many people to thank in it’s evolution.
I started the process several years ago, creating a processor that scraped emails checking for sucseful recurring payments. This work was undertaken with Community Builders for Voiceless initially.
It was then refactored into using eWay’s token based recurring payments API by Henare Deegan.
Finally, to make it work for all users and not just hard coded to work for specific clients I undertook another update to the code (also making it compatible with several versions of CiviCRM) with sponsorship from...Read more
I've been recommending the services of iATS for most of my clients' payment processing since way back in 2007, when I wrote a CiviCRM payment plugin processor for it: http://homeofficekernel.blogspot.ca/2007/12/iats-and-civicrm.html
That was a long time ago (CiviCRM version 1.8), and I've been promising myself and others that it's high time to rewrite it, because:
1. CiviCRM now has an excellent extensions architecture.
2. iATS has a new richer SOAP-based API to interact with it.
With some help from my colleague Karin and iATS themselves who helped fund it, I'm happy to report that it's now ready for public testing, at
The two things that make...Read more