Monday, February 12, 2018 - 05:03
Written by

Last week we had a Sprint in the wonderful city of Brussels. This blog post is a recap of what I have been up to.

Form Processor

I started the sprint to work on a new extension the form processor.  This idea came to my mind as I had a few clients at which I had to develop a custom api for data coming from their website (in those cases CiviCRM was separated from the website). And my idea was that I wanted to give system administrator and implementers a tool in which they could create those kind of API by themselves. So the form processor was born.

Below is a sketch of the screen of the form processor (click the image for a larger preview):

The form processor is designed so that the user first defines the input fields and after that the actions.

As you can see the form processor has actions attached to it and that looks quite a bit as the actions at the CiviRules extension. Which got me thinking. But what got me even more thinking was Björn demonstrating his SQL Tasks extension at the sprint. The SQL Tasks extension also contains actions. Hang on... So we got two extensions already in the ecosystem implementing some kind of action system. Could it not be useful to have an Action extension, so that actions provided in the action extension could be resued by SQL Tasks, CiviRules, Form Processor and others. Hence the Action Provider extension was born.

Action Provider extension

The aim of the action provider extension is to provide a framework to implement actions which could then be used by CiviRules, SQL Tasks, Form Processor and other extensions. The action provider extension should also provide a default set of actions, such as Add to group, Set contribution status to completed, Send -email etc... Like the ones already present in CiviRules.

Architecture overview

So how does this all fit in the architecture of a CiviCRM environment? Tim Otten drew a diagram about CiviCRM form/action architecture, and I've excerpted a relevant section below. In this excerpt you can see in the top part the extensions with a user interface which are all related but do different things. In the middle you see the action provider is used by the other parts of the system and the standard API.

At the bottom of the picture are external websites/systems talking to CiviCRM. As you can see many parts of the architecture already exists.

Next steps

  • Develop a proof of concept of the action provider with a proof of concept implementation in CiviRules. We have a working proof of concept of action-provider extension and CiviRules
  • Develop a proof of concept of the Form Processor extension
  • Refactor code of both extensions for publishing and use in production systems
  • Write documentation on how to implement the action provider in your extension and how to develop a custom action;
  • Write user/administrator documentation of the Form Processor




I have used as my new home for those project as this place was presented during the sprint as an alternative to GitHub. We as a community should practice what we preach (use open source whenever possible)


I have used the new short extension name for the form processor and the action provider. During the Sprint Michael McAndrew has been working on that and the reasoning behind is to remove the vendor dependency in the name of the extension so that it is easier for others to co-maintain an existing extension.

One last remark during the Sprint I have also used Michael McAndrews docker container with Buildkit; if you are experiencing troubles with setting up buildkit you should try out this docker container:


My Fast Action Links extension also provides actions - and integrates with CiviRules.  It seems like it would be worth adding support for this new approach into Fast Action Links so that, e.g., I could pass parameters in.

I suspect your approach to this problem will be different from mine, and you've already written a proof-of-concept, but there may be some ideas to be gleaned from reading my code if you feel the need.