10-Aug-2026 — Building a Rights-of-Way Volunteer System: The Group-Neutral Import Model

Looking after footpaths takes a lot of quiet organising: which parishes have someone keeping an eye on them, who that person is, which councils to write to, and how it all fits together. NGX now holds that whole picture in one place, in a dedicated volunteer workspace. The clever part is not the screens, but how any Ramblers area can load its own information without NGX needing to know how that area happens to keep it today.

The model came from a real Ramblers area that already runs footpath volunteering at scale, across almost four hundred parishes. That experience shaped what the system holds. It did not shape how the information gets in: every area hands NGX the same couple of simple spreadsheets, never its own private database.

The five things it keeps track of

Everything reduces to five things and the relationships between them.

• Parish — a civil parish, identified by its official ONS code (for example E04001129), never by name alone. The code is what keeps a parish the same parish across the map and across every area's data. A parish also carries the authority, sector and rights-of-way group it belongs to, and a flag for parishes with no public rights of way so they stay out of the vacancy figures.
• Person — a volunteer or a council contact. People are not owned by the volunteer module: everyone the system can email lives in the Ramblers supporter feed, keyed on their email address. That is a data-protection choice — Ramblers centrally is the data controller, so consent and privacy sit with the feed, not with a private address book inside NGX.
• Role — the fixed set of jobs a person can hold: Local Footpath Officer, Parish Footpath Observer and Group Coordinator. A parish has one Local Footpath Officer but any number of Parish Footpath Observers; a coordinator looks after a whole rights-of-way group rather than a single parish.
• Assignment — the link between them: this person holds this role for this parish (or group), as permanent or temporary cover, between these dates. Past assignments are kept, so a handover reads correctly rather than overwriting whoever came before.
• Contact — a parish or town council, or a local-authority office, that you write to. Held with its organisation, contact name, role, email, telephone and the parishes it covers.

The idea in one sentence

Everything the system holds comes down to one plain line:

flowchart LR
    PERSON@{ icon: "ngx:user", label: "A person", pos: "b", h: 46 }
    ROLE["takes on a role<br/>LFO · PFO · Coordinator"]
    PARISH["for a parish"]
    GROUPING["that sits in a rights-of-way group,<br/>an authority and a sector"]
    COUNCIL["with a council to write to"]
    PERSON --> ROLE --> PARISH --> GROUPING
    PARISH --> COUNCIL

A person takes on a role — Local Footpath Officer, Parish Footpath Observer or Coordinator — for a parish, which sits inside a rights-of-way group, an authority and a sector, and has a council you write to. Fill that sentence in with real names and places, over and over, and you have the whole system.

Take one example: Alice is the Local Footpath Officer for Upper Meadowford. In a spreadsheet that is a single row:

So setting the system up is really just filling in rows: one for each person, and one for each job someone does.

Two simple spreadsheets

An area prepares two files. The first lists the people — every volunteer and every council contact, each with their email address. The second describes the structure — the parishes, who looks after what, and the councils to write to. Both are ordinary Excel files with a documented set of columns, so an area can produce them whatever it happens to use today.

Two things always stay the same. Parishes are identified by their official ONS code (like E04001129) rather than by name, so the same parish lines up across the map and across everyone's data. People are identified by their email address, which is how a job in the second file is matched to a person from the first.

You can download both files, filled in with a few example rows in exactly these formats, at the foot of this page. Open them to see the shape, or import them as they are to try the process end to end.

How it goes in

Loading an area's data happens in two separate steps, and keeping them separate matters:

flowchart TB
    subgraph author["What an area prepares"]
        F1@{ icon: "ngx:file", label: "1 · People", pos: "b", h: 46 }
        F2@{ icon: "ngx:file", label: "2 · Structure", pos: "b", h: 46 }
    end
    FEED@{ icon: "ngx:ramblers-hq", label: "Supporter feed", pos: "b", h: 48 }
    subgraph ngx["NGX Ramblers"]
        MEM@{ icon: "ngx:user", label: "People", pos: "b", h: 48 }
        VOL@{ icon: "ngx:ramblers", label: "Parishes & jobs", pos: "b", h: 48 }
    end
    F1 -->|"load into feed"| FEED
    FEED -->|"sync"| MEM
    F2 -->|"import"| VOL
    MEM -.->|"matched by email"| VOL
    style author fill:#FDF3D8,stroke:#F9B104,stroke-width:2px,rx:12,ry:12,color:#404143
    style ngx fill:#E8F5EE,stroke:#9BC8AB,stroke-width:2px,rx:12,ry:12,color:#404143

1. People go in first, through the Ramblers supporter feed. Everyone the system can email — volunteers and contacts alike — is held centrally, keyed on their email. This keeps consent and privacy where they belong: with Ramblers as the data controller, not in a private address book inside NGX.
2. The structure goes in through the volunteer import. The parishes and jobs are read from the second file and matched to those people by email. Anyone who cannot be matched yet is kept safely against their name for later, so no coverage is ever lost.

Before anything is saved, a dry run shows exactly what would change — parishes, matched volunteers, jobs to add, and anyone who needs a second look — without touching a single record. Only when the numbers look right do you apply, and running it again later updates the same records rather than creating duplicates.

Why keep it group-neutral

The two files describe what every Ramblers area has in common: parishes, people, jobs and councils, not the inside of any one area's system. So an area with an old database, one with a pile of spreadsheets, and one starting from scratch all meet NGX in the same place, and the workspace works the same way for everyone.

Download the example files

The two files below carry a handful of made-up rows in exactly the formats described above. Download them, open them to see the shape, and import them as they are to try the process end to end. The people file goes into the supporter feed; the structure and assignments file goes into the volunteer import.