Skip to main content

This is a proof of concept viewer for the planning permission specifications - your feedback will help us to improve it.

Dataset

planning application

Records of applications submitted to planning authorities

Fields

Reference

The reference for the planning application

Reference
reference
Cardinality
1
Datatype
string
Requirement level
MUST
Needs this field satisfies

Fields should only be added if they satisfy a user need. This field helps satisfy the following needs.

  • This field and field received-date satisfy need dd-need-017.
  • This field and field linked-applications satisfy need dd-need-001.
Name

A plain-language label for the planning application so it can be identified without relying on its reference

Reference
name
Cardinality
1
Datatype
string
Requirement level
SHOULD

No needs satisfied by this field.

Description

The description of the proposed development

Reference
description
Cardinality
1
Datatype
string
Requirement level
MUST
Needs this field satisfies

Fields should only be added if they satisfy a user need. This field helps satisfy the following needs.

Application types

One or more codelist values describing the application type

Reference
application-types
Cardinality
n
Datatype
enum
Allowed values
Application type codelist
Requirement level
MUST
Needs this field satisfies

Fields should only be added if they satisfy a user need. This field helps satisfy the following needs.

Site

The reference for the related site

Reference
site
Cardinality
1
Datatype
string
Related dataset
Site dataset
Requirement level
MUST
Needs this field satisfies

Fields should only be added if they satisfy a user need. This field helps satisfy the following needs.

  • This field and field geometry (dataset site) and field address-text (dataset site) satisfy need dd-need-051.
Received date

The date the planning authority received the application

Reference
received-date
Cardinality
1
Datatype
datetime
Requirement level
MUST
Guidance

How to use it

Use this field to record the date the planning authority first received the application.

Do not replace it with the date the application was later validated or registered.

This date marks the start of the authority's end-to-end handling time.

Keep the original received date and record validation separately in the planning permission timeline using the defined events:

  • valid-from: the date from which the authority treated the application as valid
  • invalid-from: the date from which the authority treated the application as invalid
  • validation-completed: the date the authority completed its validation check

These dates may differ. Keeping them separate makes it possible to distinguish time spent reaching validation from time spent determining the application.

For example:

json { "received-date": "2026-08-03" }

Needs this field satisfies

Fields should only be added if they satisfy a user need. This field helps satisfy the following needs.

Planning authority

Identifier of the planning authority that received this planning application

Reference
planning-authority
Cardinality
1
Datatype
enum
Requirement level
MUST
Guidance

How to use it

Use the identifier for the planning authority that received the application.

Find the authority in the planning-authority codelist and use its reference, rather than its name or a locally created code.

For example, use local-authority:LDS for Leeds City Council.

No needs satisfied by this field.

Case officer

Name of the planning officer responsible for handling the application

Reference
officer-name
Cardinality
1
Datatype
string
Requirement level
Not specified
Needs this field satisfies

Fields should only be added if they satisfy a user need. This field helps satisfy the following needs.

Development scale

The local planning authority's classification of a full or outline planning application by development scale

Reference
development-scale
Cardinality
1
Datatype
enum
Requirement level
SHOULD
Guidance

How to use it

Use this field to record whether the authority classified a full or outline planning application as major or minor.

This classification supports the consistent production of relevant parts of PS1 and PS2 returns. It records the authority's classification and is not calculated automatically from the details of the proposed development.

Use it only for:

  • full
  • outline-all
  • outline-some

Omit the field for application types where the major or minor classification does not apply. Where it does apply, use a value from the development-scale codelist.

Needs this field satisfies

Fields should only be added if they satisfy a user need. This field helps satisfy the following needs.

Planning performance agreement

Whether the application was subject to a Planning Performance Agreement

Reference
planning-performance-agreement
Cardinality
1
Datatype
boolean
Requirement level
MUST
Guidance

How to use it

Use this field only to record whether the particular planning application is subject to a planning performance agreement.

  • Use true when a planning performance agreement applies.
  • Use false when it is known that no planning performance agreement applies.
  • Omit the field when this information has not been recorded or is not known.

Do not use this field to describe the agreement, its terms or its milestones.

Needs this field satisfies

Fields should only be added if they satisfy a user need. This field helps satisfy the following needs.

Withdrawn date

The date the planning application was withdrawn

Reference
withdrawn-date
Cardinality
1
Datatype
datetime
Requirement level
SHOULD
Needs this field satisfies

Fields should only be added if they satisfy a user need. This field helps satisfy the following needs.

Linked applications

References to earlier applications this application directly links to

Reference
linked-applications
Cardinality
n
Datatype
string
Requirement level
MUST
Guidance

How to use it

Use this field to reference earlier applications that have a direct procedural relationship with the current application.

For example, link:

  • a reserved matters application to its outline application
  • a technical details consent application to its permission in principle application
  • a non-material amendment to the permission being amended
  • an application to discharge conditions to the permission containing those conditions

Do not include every application for the same site, nearby applications or applications that are related only because they have the same applicant. Wider planning history can be found through the linked site records.

Needs this field satisfies

Fields should only be added if they satisfy a user need. This field helps satisfy the following needs.

  • This field and field reference satisfy need dd-need-001.
Document URL

A URL to the completed application form

Reference
document-url
Cardinality
1
Datatype
url
Requirement level
SHOULD
Needs this field satisfies

Fields should only be added if they satisfy a user need. This field helps satisfy the following needs.

Documentation URL

The URL where supporting documents for the application can be accessed

Reference
documentation-url
Cardinality
1
Datatype
url
Requirement level
MUST
Needs this field satisfies

Fields should only be added if they satisfy a user need. This field helps satisfy the following needs.

Notes

Optional notes that provide additional context about the planning application

Reference
notes
Cardinality
1
Datatype
string
Requirement level
MAY

No needs satisfied by this field.

Examples

These examples show how to record information about a planning application.

Basic planning application

This example shows the core information recorded for a full planning application. The application, its site and its planning authority each use their own reference.

Example formats

Table

Field Value
reference 2026/0123/FUL
name Former Crown Works redevelopment
description Demolition of the existing workshops and construction of 24 homes with associated access and landscaping.
application-types ["full"]
site site-2026-0123
received-date 2026-02-16
planning-authority local-authority:CMD
development-scale major
planning-performance-agreement false
document-url https://example.org/planning-applications/2026-0123-ful/application-form.pdf
documentation-url https://example.org/planning-applications/2026-0123-ful

JSON

{
  "reference": "2026/0123/FUL",
  "name": "Former Crown Works redevelopment",
  "description": "Demolition of the existing workshops and construction of 24 homes with associated access and landscaping.",
  "application-types": [
    "full"
  ],
  "site": "site-2026-0123",
  "received-date": "2026-02-16",
  "planning-authority": "local-authority:CMD",
  "development-scale": "major",
  "planning-performance-agreement": false,
  "document-url": "https://example.org/planning-applications/2026-0123-ful/application-form.pdf",
  "documentation-url": "https://example.org/planning-applications/2026-0123-ful"
}

Combined planning application

This example shows one application seeking both full planning permission and listed building consent. Include both values in application-types; do not create a second planning application record solely because more than one consent is sought.

Example formats


Needs satisfied by this dataset

Datasets should only be included in the specification if they satisfy user needs.

No recorded links yet.