Workbook structure
A NaturaList xlsx file contains at least three sheets that must use the following names (or names you configure):
| Sheet name | Purpose | Required? |
|---|---|---|
checklist | One row per taxon or occurrence - all your actual data, this is the sheet you will work with most often. See Data sheet. | Yes (name configurable) |
nl_content | Defines what each column means (meta), once set-up, you won't need to touch this often. See Sheet nl_content. | Only the Taxa Definition table is required; all other tables are optional |
nl_appearance | Controls visual appearance and global settings, once set-up, you won't need to touch this often either. See Sheet nl_appearance. | No - entirely optional |
Renaming and multiple data sheets
The default sheet name checklist is configurable, and you can supply more than one sheet name. See Data sheet for details.
What is strictly required
Only two things are needed for the app to compile and display a functional project:
- The data sheet (with at least one row of taxon data).
- The Taxa Definition table on
nl_content(with at least one row defining one taxon level).
Everything else - all other nl_content tables (Custom Data Definition, Search Online, Single-Access Keys, Bibliography, Database Shortcodes) and the entire nl_appearance sheet - is optional and available to you if you need the functionality. Unused tables can simply be left empty.
Start from the full template
It is strongly recommended to start from the full blank template provided by the app (downloadable from the Manage screen), which contains all sheets and all table headers pre-filled. Keeping the full template structure - even with empty tables - means you can seamlessly add new data types, appearance settings, or identification keys later without restructuring the workbook.
How the meta sheets are laid out
The two meta sheets (nl_content and nl_appearance) each contain multiple tables laid out side by side, separated by an empty column. Each table has a header row with the table name, then a row of column headers, and then data rows beneath. You can give the separator column a narrow width and a background color to make the boundaries visually clear - this formatting is cosmetic and is not parsed by the app.
The workbook as your database
Because all your data lives in a single file, it is also your entire publication pipeline. You can keep it on your own computer, in a cloud storage service accessible to your collaborators, or in a shared version control system like GitHub. The app compiles the workbook into a compressed JSON file (checklist.json) which is what user devices actually load. If you edit your spreadsheet, simply recompile and republish.
Online collaboration
Because all data lives in a single xlsx workbook (or a small set of named sheets within it), it is naturally suited to cloud-based collaborative editing. Store the spreadsheet in any cloud service - OneDrive, Google Drive, Dropbox, and so on - and share it with your collaborators. Each collaborator edits the shared file; you export or download it as .xlsx when ready to publish. There is no conflict-resolution mechanism in NaturaList itself - the app publishes whichever version of the spreadsheet is uploaded last, so coordinate simultaneous edits using your cloud platform's version history and activity log. For larger teams working on distinct taxonomic groups, the multi-sheet setup described above further reduces the risk of conflicts between contributors.
Scripted and automated data integration
The xlsx format is a standard, well-supported file format readable and writable by a wide range of programming languages and tools. For technically inclined authors, this opens the door to workflows that go beyond manual spreadsheet editing.
NaturaList does not do any of the following out of the box - these are ideas for what you can build around your workbook to suit your project's needs.
Generating the data sheet from an existing database. If your institution or project already maintains a taxonomic or biodiversity database, you can write an export script that reads from that database and produces a correctly structured xlsx workbook ready for NaturaList to compile. This sidesteps manual data entry entirely and means the checklist always reflects the canonical state of your source database. Great if you want to use NaturaList as a public facade to your existing database.
Injecting or updating fields in an existing workbook. Rather than replacing the whole sheet, a script can open an existing workbook, locate rows by taxon name or identifier, and update or add specific columns. Practical examples include:
- Querying the IUCN Red List API and writing the current threat category into the appropriate column for each taxon, so Red List statuses stay current without manual checking.
- Pulling specimen occurrence records from a herbarium collection management system and writing mapregions data or adding/updating
occurrence-type rows (see Occurrence and collection mode) to reflect the live database state. - Reading from a trait database and populating morphological or ecological columns for taxa that have matches.
When to consider a scripted approach. A script makes most sense when your data has an authoritative source elsewhere (a collection database, an institutional registry, an API-accessible resource) and manually transcribing or updating that data would be error-prone or impractical at the scale of your project. It also makes sense for recurring updates - if Red List statuses or collection holdings change over time, a scheduled script can keep your checklist current. For one-off or slowly evolving data, manual editing in the spreadsheet remains perfectly adequate.
Any language with xlsx read/write support can be used. Common choices include Python with openpyxl, R with openxlsx, or JavaScript/Node.js with exceljs. After the script runs, the updated xlsx is uploaded and recompiled through the Manage screen in the normal way.