{"id":"6a7a3b9c160ff3db8b58c9a0","title":"2026 08 10 Rights Of Way Volunteer Import Model","path":"how-to/technical-articles/2026-08-10-rights-of-way-volunteer-import-model","contentMarkdown":"# 10-Aug-2026 — Building a Rights-of-Way Volunteer System: The Group-Neutral Import Model\n\n_____\n\nLooking 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.\n\nThe 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.\n\n## The five things it keeps track of\n\nEverything reduces to five things and the relationships between them.\n\n- **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.\n- **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.\n- **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.\n- **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.\n- **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.\n\n## The idea in one sentence\n\nEverything the system holds comes down to one plain line:\n\n```mermaid\nflowchart LR\n    PERSON@{ icon: \"ngx:user\", label: \"A person\", pos: \"b\", h: 46 }\n    ROLE[\"takes on a role<br/>LFO · PFO · Coordinator\"]\n    PARISH[\"for a parish\"]\n    GROUPING[\"that sits in a rights-of-way group,<br/>an authority and a sector\"]\n    COUNCIL[\"with a council to write to\"]\n    PERSON --> ROLE --> PARISH --> GROUPING\n    PARISH --> COUNCIL\n```\n\n**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.\n\nTake one example: _Alice is the Local Footpath Officer for Upper Meadowford._ In a spreadsheet that is a single row:\n\n| Volunteer | Role | Parish | Cover |\n|---|---|---|---|\n| Alice Fieldingham | Local Footpath Officer | Upper Meadowford | Permanent |\n\nSo setting the system up is really just filling in rows: one for each person, and one for each job someone does.\n\n## Two simple spreadsheets\n\nAn 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.\n\nTwo 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.\n\nYou 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.\n\n## How it goes in\n\nLoading an area's data happens in two separate steps, and keeping them separate matters:\n\n```mermaid\nflowchart TB\n    subgraph author[\"What an area prepares\"]\n        F1@{ icon: \"ngx:file\", label: \"1 · People\", pos: \"b\", h: 46 }\n        F2@{ icon: \"ngx:file\", label: \"2 · Structure\", pos: \"b\", h: 46 }\n    end\n    FEED@{ icon: \"ngx:ramblers-hq\", label: \"Supporter feed\", pos: \"b\", h: 48 }\n    subgraph ngx[\"NGX Ramblers\"]\n        MEM@{ icon: \"ngx:user\", label: \"People\", pos: \"b\", h: 48 }\n        VOL@{ icon: \"ngx:ramblers\", label: \"Parishes & jobs\", pos: \"b\", h: 48 }\n    end\n    F1 -->|\"load into feed\"| FEED\n    FEED -->|\"sync\"| MEM\n    F2 -->|\"import\"| VOL\n    MEM -.->|\"matched by email\"| VOL\n    style author fill:#FDF3D8,stroke:#F9B104,stroke-width:2px,rx:12,ry:12,color:#404143\n    style ngx fill:#E8F5EE,stroke:#9BC8AB,stroke-width:2px,rx:12,ry:12,color:#404143\n```\n\n1. **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.\n2. **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.\n\nBefore 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.\n\n## Why keep it group-neutral\n\nThe 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.\n\n\n## Download the example files\n\nThe 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.","contentHtml":"<h1>10-Aug-2026 — Building a Rights-of-Way Volunteer System: The Group-Neutral Import Model</h1>\n<hr>\n<p>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.</p>\n<p>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.</p>\n<h2>The five things it keeps track of</h2>\n<p>Everything reduces to five things and the relationships between them.</p>\n<ul>\n<li><strong>Parish</strong> — a civil parish, identified by its official <strong>ONS code</strong> (for example <code>E04001129</code>), never by name alone. The code is what keeps a parish the same parish across the map and across every area&#39;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.</li>\n<li><strong>Person</strong> — 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 <strong>email address</strong>. 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.</li>\n<li><strong>Role</strong> — the fixed set of jobs a person can hold: <strong>Local Footpath Officer</strong>, <strong>Parish Footpath Observer</strong> and <strong>Group Coordinator</strong>. 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.</li>\n<li><strong>Assignment</strong> — 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.</li>\n<li><strong>Contact</strong> — 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.</li>\n</ul>\n<h2>The idea in one sentence</h2>\n<p>Everything the system holds comes down to one plain line:</p>\n<pre><code class=\"language-mermaid\">flowchart LR\n    PERSON@{ icon: &quot;ngx:user&quot;, label: &quot;A person&quot;, pos: &quot;b&quot;, h: 46 }\n    ROLE[&quot;takes on a role&lt;br/&gt;LFO · PFO · Coordinator&quot;]\n    PARISH[&quot;for a parish&quot;]\n    GROUPING[&quot;that sits in a rights-of-way group,&lt;br/&gt;an authority and a sector&quot;]\n    COUNCIL[&quot;with a council to write to&quot;]\n    PERSON --&gt; ROLE --&gt; PARISH --&gt; GROUPING\n    PARISH --&gt; COUNCIL\n</code></pre>\n<p><strong>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.</strong> Fill that sentence in with real names and places, over and over, and you have the whole system.</p>\n<p>Take one example: <em>Alice is the Local Footpath Officer for Upper Meadowford.</em> In a spreadsheet that is a single row:</p>\n<table>\n<thead>\n<tr>\n<th>Volunteer</th>\n<th>Role</th>\n<th>Parish</th>\n<th>Cover</th>\n</tr>\n</thead>\n<tbody><tr>\n<td>Alice Fieldingham</td>\n<td>Local Footpath Officer</td>\n<td>Upper Meadowford</td>\n<td>Permanent</td>\n</tr>\n</tbody></table>\n<p>So setting the system up is really just filling in rows: one for each person, and one for each job someone does.</p>\n<h2>Two simple spreadsheets</h2>\n<p>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.</p>\n<p>Two things always stay the same. Parishes are identified by their official ONS code (like <code>E04001129</code>) rather than by name, so the same parish lines up across the map and across everyone&#39;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.</p>\n<p>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.</p>\n<h2>How it goes in</h2>\n<p>Loading an area&#39;s data happens in two separate steps, and keeping them separate matters:</p>\n<pre><code class=\"language-mermaid\">flowchart TB\n    subgraph author[&quot;What an area prepares&quot;]\n        F1@{ icon: &quot;ngx:file&quot;, label: &quot;1 · People&quot;, pos: &quot;b&quot;, h: 46 }\n        F2@{ icon: &quot;ngx:file&quot;, label: &quot;2 · Structure&quot;, pos: &quot;b&quot;, h: 46 }\n    end\n    FEED@{ icon: &quot;ngx:ramblers-hq&quot;, label: &quot;Supporter feed&quot;, pos: &quot;b&quot;, h: 48 }\n    subgraph ngx[&quot;NGX Ramblers&quot;]\n        MEM@{ icon: &quot;ngx:user&quot;, label: &quot;People&quot;, pos: &quot;b&quot;, h: 48 }\n        VOL@{ icon: &quot;ngx:ramblers&quot;, label: &quot;Parishes &amp; jobs&quot;, pos: &quot;b&quot;, h: 48 }\n    end\n    F1 --&gt;|&quot;load into feed&quot;| FEED\n    FEED --&gt;|&quot;sync&quot;| MEM\n    F2 --&gt;|&quot;import&quot;| VOL\n    MEM -.-&gt;|&quot;matched by email&quot;| VOL\n    style author fill:#FDF3D8,stroke:#F9B104,stroke-width:2px,rx:12,ry:12,color:#404143\n    style ngx fill:#E8F5EE,stroke:#9BC8AB,stroke-width:2px,rx:12,ry:12,color:#404143\n</code></pre>\n<ol>\n<li><strong>People go in first, through the Ramblers supporter feed.</strong> 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.</li>\n<li><strong>The structure goes in through the volunteer import.</strong> 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.</li>\n</ol>\n<p>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.</p>\n<h2>Why keep it group-neutral</h2>\n<p>The two files describe what every Ramblers area has in common: parishes, people, jobs and councils, not the inside of any one area&#39;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.</p>\n<h2>Download the example files</h2>\n<p>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.</p>\n"}