Planning application submissions #98
Replies: 7 comments 24 replies
-
Explaining our work on planning application submissionsIdentifying and analysing template componentsCurrently, the standards for planning applications consist of various templates and national information requirements, each with different components such as ‘applicant name and address’, ‘waste storage and collection’ and ‘parking’. To build a foundation for standardisation, the data design team are cataloguing these components across all templates, noting how often each one appears. For instance, ‘applicant name and address’ appears on all 24 templates, while ‘parking’ is only included in a few. This analysis aims to identify the core elements needed across templates. Developing data specificationsThe primary goal is to establish detailed specifications for each component, defining exactly what type of data should be captured under categories like ‘address’ or ‘parking’. These standardised specifications will ensure that any instance of a component, such as ‘address’ follows the same format. This consistency will then be integrated into new template designs to form a cohesive, unified data structure. Creating interoperable software schemasOnce standardised components are defined, they should be used to inform software schemas. This maintains data consistency across various systems, allowing for seamless interoperability. Databases on different platforms can then exchange data effortlessly because of the shared structure. Maintaining consistency across systemsThere is a need for local authorities to move data between systems and suppliers without risking reformatting issues or data loss. Standardising data components makes these transitions straightforward, ensuring minimal disruption for planners who will continue seeing familiar input fields on their screens, only now they’re underpinned by a consistent data structure. National picture of planning activityImproving the consistency and flow of data at the planning application stage will lead to greater transparency across the planning landscape and make it possible to create a single source of the truth. This makes it possible to take a more data-led approach where it’ll be possible to track housing delivery, identify stalled sites, support building safety initiatives and see how our cities and rural areas are changing. Our next stepsForming a working groupTo make sure these goals are met, we are setting up a collaborative working group involving suppliers, users, local government and other stakeholders. Working in the openWe only have 20 places on the working group so we need to ensure that we have the right blend of stakeholders. We’re setting up and running an open community too to make sure those who can not attend the working group meetings can still see what we are doing and can contribute to the discussions we are having. This will run alongside the working group. This community-based approach would bring together commercial stakeholders and end users to refine and shape the specifications effectively. Short-term focus on specification agreementThe immediate priority is to finalise and agree upon the core data specifications, creating consensus within the working group. This initial step is critical before moving on to discussions on integrating specifications into software and establishing full interoperability. Laying the groundwork for interoperabilityAfter defining these core components, further work will focus on creating new templates and ensuring compatibility across software systems. The working group will lead these efforts, collaborating with both internal and external stakeholders to implement this standardised approach. |
Beta Was this translation helpful? Give feedback.
-
Application typesOur first step has been to define a list of the main planning application types to start with. We’ll use this list of planning application types as the basis of the data specifications for planning application submissions. We’ll work through the list to understand what information and information components are required for each. Then we’ll use the list of components to understand the specific data requirements. We understand some planning authorities and people use and refer to more specific application types or sub-types (e.g. full planning major waste or prior approval - development of toll facilities). We will look at them, in particular, to understand the key differences between the main application type (parent) and any sub-types (children), in a future stage. The first set of application types we’ll look at are all:
They are:
Your inputWe have three asks:
|
Beta Was this translation helpful? Give feedback.
-
Information requirementsHaving decided on the applications to look at, next, we want to understand what the information components for each application type are. To do this we decided to look at the existing forms. Why?The information requirements and conventions have already been built into the forms over the years they have been developed and used. So, as a first step, we will work backwards from the existing forms, using them as input to analyse. This analysis will inform the as-is set of components for each application type. Once we have this list of components, we can work through the underlying data requirements (or specifications) for each. OutcomeOnce we have the list of components it should be possible to use it to determine what is the minimum information (and data) required for each application type, whether a single type (for example, Householder) or a combined one (Household with listed building consent). It would then be possible to dynamically generate a form for any combination of applications an applicant wants to submit. |
Beta Was this translation helpful? Give feedback.
-
Components and fieldsWe have listed out all the components and fields of the planning application forms we’ve reviewed. Evaluating the elementsNext we want to evaluate each element. This is where we could do with the help from people in the community. Your expertise is needed to help us to capture, for each element:
The spreadsheetIn the recent Advisory and community sessions we trialled sharing an open spreadsheet to handle all contributions. We are going to use Googlesheets for now. As we receive your feedback we can iterate it as needs change. There is a worksheet called “Instructions” which explains how you can contribute. Essentially, in any way you want. Option 1Feel free to work directly on that spreadsheet, its open to everyone so all your contributions will be visible to anyone who access it. We just ask that if someone else has already entered something into a cell then you don’t remove it. If the cell contains text then you can add your text to the same cell. Or you can add comments. Option 2An alternative approach would be to duplicate the worksheet to make your own tab (tabs at the bottom) and work on your own tab. If you do this note that the spreadsheet is completely open and “live” so everyone will be able to see your working and be able to comment if they wish. Option 3Another alternative is to take a copy of the whole spreadsheet and work on this “offline”. If you do this then you can send your spreadsheet to the data design team or reply to this post and share it here. We (data design team) will then collate your contributions and add them into the mix. Option 4You may wish to just send us a few notes - that’s great and helpful too. Reply to this post if that’s how you’d like to do it. SPREADSHEET: planning-application-components-and-fields Managing contributionsTo help us manage this process, we have created a couple of versions of this spreadsheet and made them open for people to contribute. Plus people can duplicate and share if they wish. This might mean you come across a version that doesn’t have your contributions in it. If that happens this is probably why. Yours will still be in the version you worked on and we will ensure all contributions are incorporated into a single version. We’ll share separately, as the output of this activity. Any questions, do ask. We look forward to seeing what we get! |
Beta Was this translation helpful? Give feedback.
-
|
? comment may be in wrong place.
|
Beta Was this translation helpful? Give feedback.
-
Update - Jan 29th 2025Hi all, Here is a quick update. Over the last week, we’ve held both an advisory group and a community group drop-in session. Details of the sessions can be found on the Advisory Group page. We’ll add links to minutes, slides and videos in the coming days. I just wanted to share the planning application data specification repository link that we have recently set up. From this point, we’ll use that repository to share draft specifications and supporting datasets (enums) and track issues and discussions. We’ll still use this discussion thread to provide overall updates and will use the issues section of the new repository to focus on specific issues related to the specifications. |
Beta Was this translation helpful? Give feedback.
-
Update - Feb 14th 2025Summary of work on the planning application data specification work:
|
Beta Was this translation helpful? Give feedback.


Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Planning application submissions
This discussion is specifically for discussing work on technical specifications that relate to the data needed to submit a planning application.
It is the first part of a wider initiative MHCLG have started to look at data specifications for planning applications.
These specifications are how we plan to promote greater interoperability between systems handling planning applications, whether that is systems helping applicants prepare and submit a planning application or back office systems (BOPs) used by planning officers to review and assess planning applications.
Beta Was this translation helpful? Give feedback.
All reactions