Where Restoration Records Live, From Word of Mouth to an Adaptable Platform

Where should restoration records live?

Restoration records are the linked details of a project's land, planting, visits, measurements and evidence. For most projects, they belong in an adaptable platform such as Restoration Scope: the field app, site and plot records, maps and donor portals in one place, set up around how your project works and kept up as it grows. A small project with simple records can do well in a shared Google Sheet. Below that, in memory, on paper or in emailed Excel files, records get lost.

Disclosure: I run Restoration Scope, the adaptable platform at the top of this ladder, and recommend it for most projects, so weigh where I put it accordingly.

Where a project keeps its records decides what it can prove later, and how much work it takes to keep them right. This is the ladder I use. The table starts at the top; the sections below climb from word of mouth. Two lines on it matter most:

• Google Sheets is the threshold. It is the first level I'd call workable. Below it, move up as soon as you can. The one exception is paper, when the field or the people in it need it.
• From restoration software up, the question changes. It is no longer whether your records are safe, but whether your system can adapt when your project does.

1. Word of mouth

The worst place for a record is someone's memory. "We planted the slope by the river last March." "The landowner agreed to two hectares." It works until that person leaves, forgets, or remembers it differently from everyone else.

Nobody outside the conversation can check it: not your team next year, not a funder, not a verifier. If it matters, write it down.

2. Paper

Paper is a step up: at least the record exists. Field sheets and notebooks are sometimes exactly what the field calls for. There is no signal, phones run out of battery, or the people doing the work don't use technology.

That's fine, as long as paper is where a record starts, not where it ends. Paper gets wet, gets lost, and can only be in one place. Type it up soon. If paper is there because of the field, a field app that works offline, such as KoboToolbox, ODK or QField, may take its place.

3. Excel files

Excel files feel like a real system. They have rows, columns and formulas. But in restoration they usually live on someone's laptop and travel by email. One partner edits a copy, another edits a different one, and soon there is a file called planting final v3 REAL and nobody knows which file is current. When the laptop dies, the records go with it.

Excel kept in OneDrive or SharePoint can be shared too. But the habit I see is local files and attachments, and the fix is simple: move them to Google Sheets. I'd do that every time. Our Excel and Google Sheets comparison goes deeper.

4. Google Sheets

This is the threshold. A Google Sheet is one shared file that everyone works in. You send a link and decide who can view or edit (⁠how sharing works). There is one copy, so there is nothing to merge. Version history shows who changed what (version history). And in a shared drive, the sheet belongs to the organisation, not to one person.

At this level, though, each sheet stands alone. Someone opens one when they need it, and when a new need comes up, they start another. Soon there is a planting sheet, a nursery sheet and a monitoring sheet, each with its own list of sites.

5. Advanced Google Sheets

The next step is to connect the sheets and run them on purpose. ⁠IMPORTRANGE pulls the site list from one master sheet into the others, so it is typed once. Just as important are the rules around the sheets: each sheet has an owner, there are guidelines for adding columns, and old sheets are marked obsolete instead of left to linger.

Then come ⁠Apps Script and macros: scripts that copy rows, send reminders, check values or build a report. A spreadsheet starts to behave like an application.

This works well for a while. But it rests on people following the rules, the links break when someone renames a tab or moves a column, and the scripts usually live in code only one person understands. When they leave, nobody dares touch it.

6. Airtable and similar tools

Many organisations move on to spreadsheet-like databases such as Airtable. They are more flexible: linked records, forms, interfaces and automations you build yourself.

For restoration, three things hurt:

• Maps. Sites and boundaries are the heart of a restoration project, and Airtable's map shows pins, not boundaries.
• Nested hierarchies. Projects have sites, sites have plots, plots have trees, and each one is visited season after season. In Airtable, each level is its own table, held together by links and lookups that you design and maintain.
• Granular editing rights. Letting each partner edit only its own sites, and see only what it should, is hard to set up (⁠Airtable permissions).

Our Airtable comparison goes into the details.

7. Restoration software

Then there is software built for reforestation and restoration. We have compared many of these tools in our guides to restoration monitoring tools, ARR carbon project software, field data apps and donor portals.

The common problem is rigidity. The software does A, B and C, and you have to be fine with that. When your project needs D, you go through hoops to make it work: workarounds, exports, and other systems patched on the side.

8. A network of connected tools

So teams connect tools. A survey app for the field, a sheet for the register, a GIS for the maps, a portal for funders, all wired together with connector apps and small servers.

It can do almost anything, but it is messy. It needs constant maintenance, and it is brittle: one tool changes a field or an API, and the chain breaks somewhere nobody is looking. Our comparisons show where tools such as QGIS and explorer.land fit in a stack like this.

9. A fully custom system

Next is a system your organisation builds and runs itself. It fits you exactly, and you own every decision. But you also own the hiring, the hosting and the maintenance, for as long as you use it. I have written about the pros and cons of an in-house software team and of building a field data system with AI.

10. An adaptable platform

The top level is the one we built Restoration Scope for, and the one I'd pick for most projects. It works from ready-made modules, such as the field app, records, maps and donor portals, tuned to your data architecture and to how your organisation thinks about its work. When a module is not enough, we add fully custom code, processes and geospatial analysis at any point.

That gives you the flexibility of a custom system without building one: it adapts to your project's nuances and grows with it, and the same records help run the work, keep costs in view, raise funds and report to funders. And you don't have to give up what works: Restoration Scope can keep reading your Google Sheet.

You don't have to climb every level. Pick the one that fits your project's next stage, and if your records are below Google Sheets today, get them into one shared sheet first.

Related guides

• A hierarchy of data needs for nature restoration projects: what to record, from counts to data across time.
• A spreadsheet can look full and still be missing what matters: four tests for the records you have.
• Should a nature project build its own software team?: costs, hiring and maintenance.
• All comparisons: where Restoration Scope fits beside the tools you already use.

Frequently asked questions

Is Excel or Google Sheets better for restoration data?

Google Sheets. Excel files kept on laptops get emailed, copied and lost, and nobody knows which copy is current. A Google Sheet is one shared file with link sharing, version history and a place in a shared drive.

Is it still OK to collect restoration data on paper?

Sometimes. Paper is the right call where phones don't work or the people doing the work don't use them. Type the sheets up soon after, into a shared Google Sheet or a field app, so the record doesn't depend on one notebook.

Is Airtable good for restoration projects?

It is more flexible than a spreadsheet, and many organisations use it. It is weak at maps, at nested hierarchies such as project, site, plot and tree, and at fine-grained editing rights, such as letting each partner edit only its own sites.

Should a restoration organisation build its own software?

Only with a clear reason and a long-term budget. A custom system fits you exactly, but you pay for hiring, hosting and maintenance for as long as you use it. Our guide to building an in-house software team covers the costs.

Another question? Email us or book a call.