We proudly boast that we can integrate FixMyStreet Pro with any existing council CRM — and that’s the truth, though it’s always interesting to see what challenges each new one will bring.
Thanks to the London Borough of Bexley coming on board as our latest client, we can add Symology to the ever-growing list of systems that are proven to work in harmony with FixMyStreet.
There were two new challenges to solve to ensure a smooth integration here. First, although Symology has an API, which is the easiest way to ask a CRM to provide you with regular feeds of data, we couldn’t find a way to extract updates on reports from it. These updates are what keep our users informed of the progress of their issues, so we needed to find a different way to extract them.
No problem, thanks to Bexley’s obliging and responsive team: to get around this issue, they set up a regular CSV export for us. FixMyStreet Pro can automatically parse this and take in the contents, then publish updates on the site as appropriate.
The other challenge was that Symology has no functionality to perform ‘logic assignations’ — in other words, using the relevant fields of a report in order to send them on to the correct team, assign them the right priority, or apply analysis codes. Fortunately, we were able to integrate all the necessary moving parts into our Open311 adapter functionality, making sure reports will be directed to the right place.
A final belt and braces move is that when a report is identified as high priority, we send it to a dedicated priority email address as well as into the system, to make extra sure that it is seen as quickly as possible.
We enjoyed meeting these challenges for Bexley, who were receptive to all our suggestions and very helpful working with us to get them implemented.
Everything that happened to get this integration up and running need not trouble the residents of Bexley, of course. Reporting their issues will be smooth and simple — and that’s the end result we always strive for.
Image: Nigel Cox (CC by-sa/2.0)
Full integration: it’s one of FixMyStreet Pro’s main selling points. When a council signs up as a Pro customer, we hook our systems up to theirs. Citizens’ FixMyStreet reports drop directly into the existing workflows, and the council’s updates are fed back to them. Both sides continue to work exactly as they always have, but now they are communicating with one another.
Our dream set-up is when a council uses an Open311 interface, which makes this hookup very straightforward — but it’s pretty rare that things are that simple.
mySociety developer Struan explains the Open311 translation setup we’ve put in place, that keeps everything working smoothly and has the added benefit of keeping our code tidier. While his account is pretty easy for any reader to follow, this will definitely be of most interest to coders and council IT folk.
Struan: In FixMyStreet’s early days, all reports were sent to councils by email: this was done with a big script that essentially grabbed a list of any reports that hadn’t been sent, looked up the email address to send them to based on the council and report category, sent the email and marked the report as sent.
This was fine until we started offering proper integration with council systems. Barnet was our first council client, and initially we just added some if Barnet: use other send code bits to the script. But as more councils came on board, this wasn’t really sustainable — you don’t want code full of various exceptions for each council.
At that point we rewrote things so that the sending method was stored in the database against the council, and moved the sending code out into a set of libraries with a common interface. This meant that when the sending code got to a report, it could look up how to send it in the database and use the appropriate library to send it. This also means that from our end, changing how a council accepts reports is as easy as selecting a different option in the Send Method drop down in the admin.
One benefit of this setup is that we were able to add a method to pause sending to a council, which is handy if they are doing something like weekend maintenance. Reports get queued in FixMyStreet and we don’t get the many error emails saying can’t send to council X.
This was a fine approach, but as we added more integrations this resulted in more and more code in FixMyStreet which was fundamentally about our commercial operations and not relevant to anyone else installing the open source FixMyStreet codebase for their own country. We needed a way to move this code, and any configuration related to it, out of FixMyStreet.
One of the sending libraries that we created sends reports over Open311, which has the advantage that it’s pretty flexible and handles pretty much everything you need to communicate as part of an integration: sending reports, fetching reports, fetching updates, sending updates and fetching report categories. Obviously, it would be lovely if every council could provide us with an Open311 interface, as we could just plug that in directly. Sadly this is not the case.
So, we did the next best thing: we provide our own internal Open311 interface to FixMyStreet which then translates Open311 calls into whatever format the customer’s system requires. This removes the need to add code to FixMyStreet for a new integration, and it also moves lots of the integration specific configuration out of FixMyStreet too.
It works by using the jurisdiction_id that Open311 passes in to load up the correct configuration so most of our council integrations look pretty much the same on the FixMyStreet side.
Inside the Open311 adapter code we do various things to make the actual back end system work like Open311 expects. Some of the calls Open311 makes require multiple calls to an integration to carry out so the adapter does those and aggregates them for the response. We also do things like transforming complicated hierarchies of attributes representing category types into a much simpler list.
The Open311 adapter itself is stateless: it simply translates calls from FixMyStreet and hands back the results. Overall, it makes things much simpler on the FixMyStreet side and moves a load of irrelevant code elsewhere. So far it’s working pretty well with six integrations running through it.