How to define flowchart connections in CSV
How to write the Line to and Line text columns in a CSV file: row positions rather than step names, branch labels paired by position, the comma that splits a label in two, and what inserting a row does.
A worked example, stage by stage
Rows and shapes, no arrows yet
The first seven rows carry Box text and Shape and nothing else: a Start, an Input recording the order number, and five diamonds ending at "Is the item physical or digital?". The canvas shows seven loose boxes. Every question in the policy is written down and not one of them has an answer path, because Line to is still empty.
Line to points at row positions
Now the positions are filled in. "Order found in the system?" has Line to reading 5,4 and forks two ways; "Is the item physical or digital?" reads 8,11 and splits the tree into the physical branch and the digital one. Note that 5,4 is not sorted: the order in the cell is the author's order, and it is the order Line text will be matched against.
Line text labels the exits
"How old is the order?" pairs 7,6,21 with "Within 30 days,31 to 90 days,Over 90 days": three positions, three labels, matched left to right. None of those labels contains a comma, and that is deliberate rather than lucky. Row 14, "Replacement or refund?", points at 19,12, and 12 is above it: a backward arrow to "Calculate the full refund amount" that looks like an error and is exactly right.
Terminators and lanes
The last rows are the five ways this tree can end: a Reject row, "Request closed with no reply" as an End, and three Success rows for the refund, the store credit and the replacement. Their Line to cells are empty, which is how a terminal step is declared in CSV: an absent value, not a keyword. The two lane columns then place all 25 rows across Request through Settlement and Customer through Finance without touching a single connection.
How it works
Fix the row order before writing any positions
Line to refers to positions in the file, so the file's order is load-bearing. Sort the export once, exactly the way you want it, and stop sorting it. If the rows arrive from a system that re-orders on every extract, freeze them into a working copy first, otherwise the numbers you write today address different steps tomorrow.
Number the data rows starting at 1 below the header
The header row is not a data row and does not count. The first step in the file is position 1, the next is 2, and so on down. Put those numbers in a scratch column while you work; the importer does not need it, but you do, because you are about to type twenty references by hand.
Write single-successor steps first
Walk the file top to bottom and give every straight-through step one number in Line to. This is fast, it is hard to get wrong, and it leaves only the forks needing thought. Leave the cell empty on a step that genuinely ends the process: an empty Line to is what makes a row terminal.
Write the forks as comma-separated positions
On each decision, put every destination in one cell: 7,6,21 means three exits. Whitespace around the commas is trimmed, so "7, 6, 21" is fine. What matters is the sequence, because you are about to write a second list that has to line up with it entry for entry.
Write Line text in the same order
For a Line to of 7,6,21 write Line text as Within 30 days,31 to 90 days,Over 90 days. Read them as pairs before you move on: first position with first label, second with second. Nothing checks this for you, and a crossed pair produces a chart that is confidently, plausibly wrong.
Drop the file in and read the arrows back
Drop the .csv onto the spreadsheet area of a new chart, or paste the text into it: there is no import wizard and no column mapping step, because the header names are matched directly. Then trace two or three branches on the canvas against the policy. Out-of-range positions and unlabelled exits show up immediately at that size.
Frequently asked questions
Why row positions instead of an ID column?
Because a CSV that comes out of another system rarely has a stable key you can use, and the ones it does have are usually record identifiers rather than step identifiers. The row position is always available, always unique and needs no agreement with whoever produced the export. The cost is that the position is only meaningful while the order holds, which is why row order matters more in a CSV flowchart than in any other format.
Do I count the header row when I number positions?
No. Position 1 is the first data row, immediately below the header. This trips people up when they are reading positions off a spreadsheet, where the header is row 1 and the first step is row 2, everything is off by one against the file. If the arrows all land one step early, this is usually why.
Can a step point at more than two rows?
Yes, and decision trees routinely do. In the example, "What condition is the item in?" has three exits and "Supervisor approves the payment?" has three, one of which is a rejection. Put all the positions in the one cell, comma-separated, and the same number of labels in Line text. There is no limit that matters in practice; readability gives out long before the format does.
What happens if Line to names a row that does not exist?
The connection is dropped and nothing is reported. A position past the end of the file, a blank left where a number should be, or a leftover number from a version of the export with more rows in it all produce the same result: an arrow that simply is not there. This is the failure mode to check for after any edit to the file's length. See /csv-to-flowchart for the full round trip.
Can I use the step's name in Line to instead of a number?
No: the column is read as positions. Names would also be ambiguous in most real files: this tree has two rows that both end in "approves" and several that read as variants of the same question. A number is unambiguous by construction, which is the reason the identity is positional and not textual.