The full organisation export

The register download in the previous topic is one entity as a spreadsheet. This is everything, as one archive.

How it differs from the register download

The CSV from Reports home is one entity, your individuals, in a spreadsheet. The full organisation export is your entire workspace in one archive file. Two different mechanisms for two different purposes, so never describe the CSV as an export of everything.

The register download lives in Reports. The full export lives in Backups, a separate area with its own permissions.

Requesting one

In your workspace, open Backups. If your role may download backups you will see Create backup now. The platform also takes scheduled backups on its own, so there is usually something waiting already.

Each backup row carries a Download button, which opens a short dialogue offering two choices: an encrypted archive using AES 256 with a password you choose, or a plain archive. The archive is assembled on request rather than kept ready, so there is a short wait and then it downloads.

• Manual backups are capped for each day, and only one archive is assembled at a time for a workspace.
• The password you choose is used once to write the archive and is never stored. Nobody at CommonLynk can open your encrypted archive for you, and a lost password cannot be recovered.
• Separately from that choice, everything the platform stores is encrypted where it sits, and the download is streamed out through the platform rather than handed over as a bare storage link, so it stays behind your permissions throughout.
• Every administrator on the account is notified by email when a backup is made and when one is downloaded.

What is inside

A package holds spreadsheets and CSV files, your original uploaded files, and a portable copy of the database, in folders by area:

• Organisation profile & settings
• Registrations / Individuals
• Registrations / Households
• Registrations / Establishments
• Registrations / Registration configuration
• Implementation / Programs
• Implementation / Projects
• Implementation / Activities
• Implementation / Attendance
• Implementation / Indicators
• Implementation / Reports
• Forms
• Users
• Dashboard
• Support
• Attachments

An assembled download stays ready for a few days, then expires, and you can build another. Backups themselves follow a schedule of recent daily, weekly and monthly copies plus a number of manual ones. When one ages out its files go, but the entry stays for your records, marked as no longer downloadable. There is no way to delete a backup yourself.

The manifest

Every package carries a manifest recording the package format version, when it was generated, the moment the data was read, your workspace name, the languages, a record count per sheet, a checksum per file, the exact software version it was built from, the database migration state, the frozen list of column headings, and what was deliberately left out.

That is what lets a package taken today still be understood and restored months from now. Column headings are never renamed or reordered once shipped, so a mapping built against one export keeps working against the next.

What is deliberately left out

Each gap below is recorded in the manifest as an exclusion rather than passed over in silence.

• The import ledger: which spreadsheet was uploaded, by whom, and what each of its rows did. The records an import created are included like any others, and your own workspace activity log, inside the portable database copy, keeps the lasting account of each import.
• Password hashes and any sign in secrets.
• API keys, encrypted credentials and tokens, which would in any case be meaningless outside the platform.
• Platform wide audit records and platform internal columns. Your own workspace activity log is included, inside the portable database copy.
• Notes visible only to support staff, and technical diagnostics. Your own support tickets, their conversations and their attachments are included.
• Rows you had already deleted.
• The reporting tables the dashboards read. They hold nothing of their own: every row is derived from the enrolments and attendance this package carries, and they are rebuilt from those after a restore.
• Indicator figures the platform calculates rather than stores, which are worked out again after a restore. The data points and targets behind them are included.
• Intermediate scoring artefacts from forms. Submitted answers, including repeat groups, are included.
• Browser session rows and cached data.
• Scanned attendance sheets uploaded to activities. Their records are in the portable database copy; the files themselves are not yet placed in the archive.
• The raw complete database dump, which would necessarily carry the sign in tables. A cleaned portable copy ships in its place: the same table structure, with credential rows and every stored password emptied, so it loads into an empty database.
• From the portable database copy: the contents of the sign in session, invitation, API key and email credential tables, and every stored password. Those tables keep their structure, so the copy still loads into an empty database.
• Which version of each form your collectors' devices last reported holding, the respondent list last sent to each device (which records, and when), what each device reported it has not sent yet, and whether it has taken a completed form off itself. It describes their phones rather than your data, and the next sync rebuilds it; the records travel in the portable SQL dump.
• Single sign on settings: your sign in providers and their public certificates, the email domains you proved, and which work account opens which workspace account. They are in the portable database copy, so a restore keeps everyone's link; the provider secrets are not, so the owner enters them again.
• Sign ins in progress and the guard against a sign in being used twice. Each lasts minutes and is deleted within two days.
• The XLSForm workbooks each form was built from, at every upload: the file name, who uploaded it and when, and the workbook itself. They are your own source files, kept so an import can be checked and repaired from the file that produced it. The records travel in the portable SQL dump and a restore brings them back; each workbook can be downloaded from its form.
• The datasets attached to forms and read by pulldata(): each uploaded file, its rows, the key column, who uploaded it and when, and which form versions carried it. They are your own reference files, part of each form version. The records and their rows travel in the portable SQL dump and a restore brings them back, with the link to every version that carried them; each file can be downloaded from its form.
• The session by session attendance grid: each activity's sessions and every person's mark in each one. It is in the portable database copy and a restore brings it back; the Attendance spreadsheets carry each person's enrolment and overall status, but not yet the individual session marks.
• Custom fields your organisation added, and the values recorded in them. They are in the portable database copy and a restore brings them back, but they have no spreadsheet yet.
• Your location tree, including places you added or edited, the names of its levels, location settings including a place's own time zone, and your country groups. Each record shows its location by name; the tree itself is in the portable database copy and a restore brings it back.
• Workspace settings and reference lists that have no spreadsheet of their own, such as activity types and templates, attachment types, disaggregation categories, email templates and saved import mappings. Records show them by name where they use them; the settings are in the portable database copy.
• Record access settings and their history: which records each user may see, record assignments, field visibility policies, emergency access grants, access reviews, confidentiality undertakings, and who was removed from which project with the date their read only access ends. The Users spreadsheets carry accounts and what each role grants; these finer records are in the portable database copy.
• Who may approve indicator readings (each person’s approval rights on projects and indicators). They are access control and are not restored: after a restore, assign approvers again. Readings already approved keep who approved them.
• Each user’s saved searches and chosen list columns: view preferences, not workspace records. A package restored without them simply opens every list on its default search and columns.
• Each record's History: who created it, under which partner and how; every later change with its old and new values; internal notes; and the dated history of each person's membership of an implementing partner. It travels in the portable SQL dump, and a restore brings it back with its records.
• Your workspace's own logs: the audit trail, the record access log, the outgoing email log and the administration log. They record how the workspace was used rather than your data, and they are in the portable database copy.
• Internal bookkeeping tables of the software itself. They describe the application, not your organisation, and are in the portable database copy so that it restores whole.
• Tables the platform no longer writes: the uploaded respondent lists forms used before 26 September 2026. Any rows they still hold are in the portable database copy.