Exporting your data

Almost nobody evaluates export properly when choosing a system, and it is completely understandable. You are deciding whether to start using something, and how easy it is to stop feels like the least interesting question available.

It is also the question that matters most, because it is the one you cannot revisit. Every other shortcoming can be worked around, tolerated or fixed by changing supplier. The ability to change supplier is the thing that makes all of that true, and if it turns out to be missing you discover it at the exact moment you have the least room to act.

So here is the recommendation, and we would give it about any supplier rather than specifically about us. Run an export on the first afternoon, before there is anything in the system worth losing. You learn what it actually produces, you learn that it works, and it costs ten seconds while the stakes are nothing.

What to look at when you do

Open it. Can you read it without our software? Are the fields recognisable? If you handed it to somebody and asked them to rebuild your customer list, could they?

Those three questions separate a real export from a technical compliance with the word. A file in a proprietary format that only the supplier's tools can read satisfies a sentence on a website and helps nobody.

The full export

From the organisation settings, if your role permits it. There is nothing to arrange with us, no request to raise and no approval on our side. It is generated on request rather than being a nightly extract, so what you get is the state at the moment you asked.

It is not limited by your plan's allowances. An organisation that dropped from a paid plan to Free holding more relationships than Free permits still exports all of them. Limits apply to adding more, never to taking things out.

Exporting one list

Any list or saved view exports as it stands, with the rows and columns you built. This is the one most people use day to day: if you have constructed the question in the product, the answer should come out in the shape you built rather than as a generic dump you filter again in a spreadsheet.

On a schedule

There is no scheduled export today, so this is a habit rather than a feature. Once a month or once a quarter, run one and keep it somewhere we do not control. Cloud storage you own, or a machine in your office.

This is the single most valuable continuity control available to you as a customer of any small supplier, because it is the only one that does not depend on the supplier still being there. We would recommend it even if we were considerably larger than we are.

Open it, on the first afternoon

Not because we expect it to be wrong. Because the only time you can safely find out what an export produces is when you do not need it to work, and that time is now rather than on the day you have decided to leave.

The formats open in a spreadsheet and in any programming language without our software. That is the property that makes it portability instead of a feature, and it is worth confirming with your own eyes.

Check the four things that matter

Are your relationships there, with the fields you actually use? Are the connections between them there, with their roles and dates? Are your notes and timeline entries there? Are the files there, and can you match them to the records they belong to?

Those four cover almost everything anyone needs from an export. If any of them is not what you expected, that is worth telling us about immediately rather than discovering later.

Keep one somewhere we do not control

This is the whole point of the exercise. A copy on your own storage, on a schedule you set, is the answer to the question every buyer should ask a supplier of our size, and it is entirely in your hands rather than dependent on anything we do.

We would give the same advice about any small supplier, including ourselves. It is not a comment on our intentions, it is arithmetic about risk.

Do it again periodically

Quarterly is plenty for most organisations. The value is not the individual file, it is that a current copy always exists, and the habit is what produces that instead of any single export.

What an export is not

It is not a report. There is no interface for exporting a chosen subset with chosen columns, because a partial export is exactly the thing that turns out to be missing something on the day it matters. You get everything you are allowed to reach, which for an owner is everything and for somebody without the grant for sensitive records is everything else with a count in the manifest of what was held back, and filtering afterwards is a spreadsheet problem rather than a portability one.

It is also not a subject access response. Subject access tooling is in the product on every plan and it answers about one person, which is what a request asks for. The export answers about everyone, so somebody reaching for it with a clock running has taken on the much harder job of removing the everybody first.

The export you took last month still contains somebody you have since erased

New exports do not include records erased under a data protection request, because erasure means removed rather than hidden. The file you took before the request arrived is a different matter entirely. It sits on your storage, it is your copy, and nothing we do reaches it. What you owe the person who asked is set out by the Information Commissioner's Office rather than by us, since your organisation is the controller of those records.

That is not a gap in the product. It is the ordinary consequence of holding your own copy, and it would be true of any supplier who gave you one. What it does mean is that an erasure request has a second half that belongs to you: finding the exports that predate it and deciding what happens to them. Few exports in one known place makes that a five minute job. Many exports, everywhere, makes it an afternoon of guessing.

Someone is working while it runs

It is generated on request, so what you get is the state at the moment you asked rather than a picture of a quiet system. If a colleague saves a note while the file is being assembled, whether that note appears in it depends on when the note landed.

For the purpose an export serves this does not matter, and we would rather say so plainly than imply a guarantee we have not made. If you are taking an export specifically because you are about to do something irreversible, take it when no one is working. That is a scheduling decision rather than a setting, and it is yours.

A module you have stopped paying for

Modules are bought separately from plans, and stopping one does not empty it. The records that module wrote stay in the export, so an organisation that ran projects for a year and then stopped still exports every project it created.

This is deliberate, and it is the version of the rule that costs us rather than you. The alternative, where the data you are able to take out shrinks the moment your bill does, turns a portability promise into a lever. A lever is exactly the thing this page exists to say we are not holding.

The person who ran the last one has left

An export is run by a person holding a role, and the file goes wherever that person put it. When they leave, the role goes with whatever process you use for that. The file does not, because the file was never in the product to begin with.

Ask the question now rather than then. If your last three exports live on a laptop that goes home with somebody in April, you do not have a continuity control, you have a person. Storage the organisation itself owns fixes this and costs nothing but the decision.

Two organisations, one person, one habit

There is one database per organisation, so there is one export per organisation. Someone who belongs to a charity and to its trading subsidiary runs two exports and gets two files, and neither file contains a line from the other.

That separation is the same one that stops either organisation reading the other's records, so it is not an inconvenience we could remove without removing something better. What it does mean is that a quarterly habit has to happen twice, and the one people forget is always the smaller organisation.

Nobody has signed in for six months

A free organisation no one signs into is treated as dormant. Its administrators are written to at six, seven and eight months, each time offering a complete export, and at twelve months the organisation is closed rather than deleted: a final notice, then thirty days in which an owner can sign in, export, or simply reopen it.

Those letters exist because deleting quietly on a timer is the one routine operation capable of destroying someone's only copy of their data, and we would rather write three letters than run that. If one arrives, the right response is to run the export in the minute you finish reading it. The common response, which is to file the letter and mean to look at it, is how organisations lose things no one intended to take from them.

The letters exist instead of a cheaper mechanism because of an argument we lost with our own arithmetic, written up in what a free plan costs. It is the clearest example on this site of a database decision arriving on a customer's doormat.