Importing values with line breaks — e.g. Comments/Notes fields

It’s not made explicit in the docs, but a Marketo CSV import does indeed support values with embedded line breaks as long as you use RFC 4180-style syntax.

If you don’t know, RFC 4180 is the closest we’ve got to an official standard for what a CSV, well, is. The RFC is Informational, so it’s not binding like a true Standard. But it covers a bunch of advanced cases very well, and if you’re writing a thing you call a “CSV parser,” you try to hit as many of its points as possible.

Anyway, in §3.6, the RFC is quite clear about how you put a line break (a.k.a. CRLF, ASCII 13 + ASCII 10, etc.) inside a value without accidentally creating a new line. You just quote the value!

So a live CSV would simply look like this:

Email,Comments
sandy+testmultiline@email.test,"This
Is
Multiline
Data"
sandy+testsingleline@email.test,"This is a single line of data"

In a CSV, quoting a value is the only way for it to contain a literal quotation mark (") or a literal comma (,), but it also allows the value to contain a literal line break, rather than the line break starting a new row in the file.

Blow your mind a li’l bit? ☺

One thing to note

When you look at a Lead’s Activity Log, you won’t see the line breaks, which can be confusing...

... but they are stored, as shown when you find the field:

This is because the Activity Log (both the full list view and the detail popup) outputs the value inside a generic HTML container, while the lead field editor (or whatever we call that UI!) uses a <textarea>.

And as you already might know, line breaks aren’t displayed in HTML <div>s unless you take specific steps to note that they’re preformatted text. A <textarea> widget reveals that the line breaks are truly there.

While we’re on the topic

I’ve also noticed some people think a quoted value in a CSV means it’s a string, while an unquoted numeric value is a number. This isn’t the case! The values in a CSV are all text values, or let’s say character sequences (just like HTML form fields). They don’t have a datatype until the app that parses the CSV decides to save and/or interpret them as Strings vs. Integers vs. Floats vs. Booleans.

So this row:

"sandy+test0001@email.test",99,33

Is the same as:

sandy+test0001@email.test,"99","33"

It’s up to the app to determine the final datatype of those numeric strings (I’ll refrain from calling them “numbers” to make my point!). For example, merely by inserting a literal '99' into a SQL INT column, you’ve converted it to an INT 99 for when you next read it.

A proper CSV parser uses quotation marks as a guide for separating values from their neighboring text, but not for deciding datatypes.

Note to coders out there

This is why parsing a CSV in all of its possible flavors is more than just .split(/\r?\n/).

Not that I don’t do it that primitive way myself if there’s not a CSV parsing library available. But we have to know that we aren’t supporting all the things users will justifiably call a “CSV.”