We've contributed our recent work on Drupal Webforms back to the community. Here, Laurie and Simon tell us all about their mini-sprint to get the work shipped in time for LocalGov Drupal Camp.
Background
We’ve been working with Walsall Council over the last 18 months to help them move from a legacy forms platform to Drupal Webform on their LocalGov Drupal site. That work gave us intimate knowledge of Drupal Webform's inner workings, and we wrote a case study on it here. It also left a backlog of features we built along the way that never made it back to LocalGov Drupal at the time. These covered everything from how residents fill in and submit forms to how council teams manage and respond to them.
Working closely with Walsall on their specific needs has given us a solid understanding of how solutions built for one council can be shaped to work for others across the community. Now we want to share that.
So once the dust settled, we decided to dedicate time to getting that code into LocalGov Drupal. We identified the features that would have the most impact for the community, which we describe below, and Laurie and Simon spent the last week on a mini-sprint to get code into the LocalGov Drupal platform in time for LocalGov Drupal Camp in Sheffield this week (11 June 2026). If you are reading this in time, come along and say hello at our stall!
The team
Laurie and Simon, who both worked with Walsall in previous phases of the project, were the primary developers on this work, with a very special guest appearance at the sprint kick-off from long-time Agile Collective collaborator, Ekes.
Getting it all ready
Before we kicked off the week, the first job was a thorough review of each feature we had developed for Walsall to determine whether they could meet needs beyond their original purpose. Reviewing code you haven’t looked at for over a year is always ‘interesting’, fortunately, the comments were good, so it didn’t take too long to get back up to speed.
From this review, we created user stories that outlined the high-level feature and the specific code, files, modules, or functions that delivered it. We also added suggestions to make the features more useful to the wider community, improve their test coverage, and make them more maintainable as community code.
Features
Custom reference numbers
Drupal.org issue: https://git.drupalcode.org/project/localgov_forms/-/work_items/3584156
Anyone who fills in a form wants a reference number, it’s proof that it went through and something to quote if it needs chasing up. It’s a standard part of the GOV.UK Design System’s confirmation pages pattern, so we built it into the core LocalGov Forms module. You can turn it on for any form, choose a format and then show it on a confirmation page or in emails, and it can be searched for by those handling a submission.
Filter on submission contents
Drupal.org issue: https://git.drupalcode.org/project/localgov_forms/-/work_items/3584155
By default, Drupal provides a very basic view of form submissions with limited filtering options. This feature lets you create filters based on how residents have completed a form. So if you are asking what type of parking permit someone is applying for, you can filter your submissions by the requested permit type to see exactly what you are looking for.
Grouped webforms and submissions
Service teams should see only the form responses relevant to them. If you want to give your teams access to form responses directly in Drupal, you also need to make sure they can only see responses for the services they deliver. This feature lets you create groups of forms and submissions, giving each team access only to what they need, keeping resident data secure, and ensuring the right people can find what they are looking for.
Email links for draft submissions
This feature lets people save an unfinished form as a draft and emails them a secure link so they can pick up where they left off. Once an email address has been added to a form, a ‘Save draft’ button appears, so a draft is never saved without somewhere to send the link.
LocalGov… case?
Name to be confirmed…. All those services you run that don’t have a line-of-business system but don’t justify bespoke development now have a home. Create a case type, define the case statuses and add fields to capture any other relevant case data in the same way you create all of your other content types. LocalGov case enables the automatic creation of a case when a form is submitted, allowing you to allocate it to yourself or to team members, update its status and add notes about its progress, all accessed from an easy-to-use case dashboard.
The week in review
Throughout the week, we encountered a number of challenges.
- We had to remember why we wrote all the great code in the first place.
- We needed to learn the new Drupal contribution system.
- We had to find time, alongside other projects, to dedicate to this work.
But the results are rewarding, taking code written for one client, for one project, and turning it into features that can be used by people across the LocalGov Drupal community, reminding us of the real benefits of open source code and cooperative working.
As we wrap up the sprint, there are still a number of outstanding stories we hope to have ready in time for LocalGov Drupal Camp.
- We need to get the LocalGov Case feature in a state where it’s ready to be shared with the community.
- We need to bring together the code and example forms to fully implement the GDS confirmation pages pattern.
As well as a backlog of further features, we plan to implement as part of Agile Collective’s open source contribution time, time that we as a company commit to giving back to the community.
If you want to learn more about any of the work mentioned above, how you can use it, or how to contribute to the project, please check out the Drupal issues listed here or reach out to us. You can find us at LocalGov Drupal Camp, on the LocalGov Drupal Slack, or via email at hello@agile.coop.
