A CSV export looks escaped
CSV export neutralises formulas. A cell whose text a spreadsheet would run as an instruction rather than read as data is written so it stays text, which is why a few cells arrive looking escaped. The file is correct; the appearance is the defence. It matters because a CSV is opened by a spreadsheet that executes what it finds, and some of what it finds was typed by somebody outside your business.
What you are looking at#
Open an export and most columns look exactly as they did on the sheet. A handful do not: a cell that started with an equals sign, or with a plus, minus or at sign, now carries a leading character that was not in the record. Depending on which spreadsheet you use, you will either see that character or see the cell quietly marked as text.
Nothing was corrupted and nothing was truncated. The underlying record still holds what it always held — open the same row in #/data and the original value is there. What changed is how the value is written into a file format that has no way of saying *this is data, not code*.
Why the export does this#
A CSV is a text file with no types and no instructions about how to treat its contents. Spreadsheets fill that gap by guessing, and one of the guesses is that a cell beginning with an equals sign is a formula to evaluate. A leading plus, minus or at sign is treated the same way by common spreadsheets. That guess is fine when you wrote the cell yourself and dangerous when you did not.
- Records contain other people's text. A company name, a note taken from an enquiry, a subject line from an inbound message — none of it was typed by you.
- An export leaves the boundary. Once the file is on a laptop it is opened by whatever the person has installed, with whatever that program is willing to run.
- The damage is not visible in the file. A hostile cell looks like a short string until something opens it and acts on it.
- The fix has to be at the point of writing. Nothing downstream knows which cells came from outside, so neutralising has to happen when the file is produced.
What Connect completed#
- The export ran and the file is complete — every row and column you selected is present.
- Each value is preserved. Neutralising changes how a value is written, not what it is; the characters of the original are still in the cell.
- The stored record is untouched. Nothing about the export writes back to the workspace.
So a neutralised export is a successful export. If you are deciding whether to run it again, the answer is that a second run produces the same file.
What Connect did not complete#
The export does not convert values into a form another system will necessarily accept. A downstream import that treats the neutralising character as part of the value will store it, and you will end up with a field that is one character longer than it should be. That is a job for the receiving system's import settings, not something the export can decide on your behalf.
Nor does Connect produce a second, unprotected copy for machine use. There is no raw variant of the same export, so a pipeline that needs unmodified text should read the records through the API rather than through a spreadsheet file format.
Reading the file without losing anything#
Import the CSV rather than double-clicking it, and set the affected columns to text.
Result The spreadsheet stops guessing, and you see the values as written without any evaluation step.
If you need the original characters exactly, strip the leading neutralising character in one pass over the column.
Result One find-and-replace on one column is safer than editing cells individually and missing some.
For a system-to-system transfer, use the API instead of a CSV.
Result Typed fields cross the boundary as themselves, and no format in the middle has to guess what they are.
For a person who just needs to look at the data, share a filtered view in the grid.
Result Nobody exports anything, and the question of what their spreadsheet would run does not arise.
An administrator cannot switch neutralisation off, and there is no per-workspace exception. What an administrator can do is set expectations with whoever receives these files — the leading character is a known, documented behaviour rather than a defect in your data.
Escalate only if a cell's content is genuinely different rather than differently written — characters missing from the middle of a value, or a column that is empty in the file and populated on the sheet. That is not neutralisation and is worth reporting with the sheet and the column.
Questions#
Does this affect every cell?
Only cells whose text a spreadsheet could read as the start of a formula. In a typical export that is a small number of them, which is exactly why it looks like an inconsistency the first time you see it — most of the file is untouched and a few cells are not.
Will re-importing the file into Connect keep the extra character?
An import maps columns to fields on the real record and applies the owning service's validation, so a value that arrives with a stray leading character is stored with it unless something rejects it. Round-tripping data through CSV is worth avoiding for exactly this kind of reason; edit in the grid instead.
Is a phone number affected?
It can be, because a number written with a leading plus starts with a character spreadsheets treat as arithmetic. Storing the number in its international form is still right — the export is protecting the file, not correcting the record.