CSV to flowchart template (support ticket triage)
Turn a helpdesk CSV export into a flowchart. Support ticket triage from submitted to closed, drawn from three columns (Shape, Box text and Line to) with a chase window, an escalation gate and a capped reopen.
What the csv to flowchart template (support ticket triage) process is
A CSV file is a text file with a header row and then one record per line, fields separated by commas, any field containing a comma or a line break wrapped in double quotes. That is the whole format. It has no formulas, no second sheet, no cell colours, no column widths and no notion of a number as distinct from the text of a number. Everything a spreadsheet adds on top is gone by the time the file lands in your downloads folder, which is exactly why systems emit CSV: it is the lowest common denominator that survives being handed between two programs that agree on nothing else. The cost of that is that a CSV carries no meaning of its own. Whatever a column means lives in its header name and nowhere else.
So the file you have is probably not a process yet. A helpdesk export has one row per ticket (an id, a subject line, a priority, a queue, an assignee, an opened date, a status) and every one of those columns describes an outcome. Ticket 40871 ended up in the network queue at priority 3, closed. Nothing in that row says how it got there, and nothing in the file records that the escalation from first line to the specialist queue is a step at all. A flowchart is made of edges, and a ticket export has nowhere to put an edge. That is the gap you are closing, and it does not require reworking the export: it requires a different file, in the same format, where a row is a step in the process rather than an instance of it.
Three columns draw a chart, and only three. Shape says what kind of box the row is: Start, Process, Decision, End, Success, Reject. Box text is the label inside the box. Line to holds the row numbers this row connects to, comma-separated, and that is the one that catches people: it is the position of the target row in the file, counting the first data row as 1, not a ticket id and not anything the helpdesk assigned. A fourth column, Line text, labels the connectors in the same order as the numbers in Line to, so "4,5" beside "Yes,No" means row 4 is the Yes branch. Everything else is optional. Horizontal lane and Vertical lane place the box in a grid of stages and roles; Line style, Notes and Link decorate it. The import matches on header names, not on column positions, so extra columns are carried along and ignored: you can leave the ticket id in the file if it helps you check your work.
What breaks is almost always the file rather than the process. A file exported under a European locale separates its fields with semicolons, which makes every line one long field. A file saved in a legacy code page renders accented names and non-Latin subject lines as replacement characters, and that damage is in the bytes, not in the drawing. Some exporters write two or three lines of preamble above the header row, so the names the import is matching on are not on line one. A label containing a comma splits into two labels unless the field is quoted. And a Line to value naming a row that does not exist points at nothing at all: no error, no warning, just a box sitting on its own with no arrow leaving it. Open the file in a plain text editor once before you import it; every one of these is visible in ten seconds and invisible afterwards.
The chart below is deliberately small: eighteen rows, five shapes, six decisions and two endings, across five stages and three lanes. It is meant to be legible at a glance and to be the thing you copy, rename and cut down. Change the labels to your own queues, delete the escalation path if you have no second line, and keep the two things most triage charts leave out: a stated way for an unanswered ticket to end, and a reopen route that does not send the work round the same failed fix a second time.
What this flowchart covers
In this template
- Five stage columns (Raise, Triage, First line, Escalation and Close) crossed with three lanes: Requester, Service desk and Specialist team, so the queue column of a helpdesk export becomes a position on the page rather than a string in a cell.
- Eighteen rows using five shapes and no more: one Start at "Submit a ticket", plain process steps, six decisions and two terminators. The Shape column of an imported CSV needs no wider vocabulary than that to draw a complete process.
- A completeness gate at "Enough detail to work the ticket?" whose No branch runs to "Ask the requester for the missing detail" and then to "Reply received before the chase window closes?", so a ticket waiting on its requester has a stated way to end.
- A first-line boundary at "Can first line resolve it?", with "Apply the documented fix" behind the Yes branch and "Record what was tried and hand the ticket over" on the way out, so the escalation carries the failed attempt with it instead of starting again.
- The split between an incident and a problem, drawn at "Fixed, or working around it?": a workaround branches through "Raise a problem record for the underlying fault" before rejoining, so the fault outlives the ticket that reported it.
- Two endings and one capped reopen: "Ticket closed" once the requester confirms, "Closed, no reply from the requester" when the chase window runs out, and a Still broken branch that returns to "Assign the ticket to the specialist queue" rather than to first line.
When to use this template
- You have a CSV export from a helpdesk sitting in your downloads folder, no diagramming tool installed, and somebody has asked you what the triage process actually is.
- The export tells you where every ticket ended up and nothing about how it got there, because a status column records an outcome and a process is made of the steps between outcomes.
- You are moving between helpdesk tools and CSV is the only format both ends agree on, so the process documentation has to survive in plain text too.
- Tickets stall waiting on the requester and nobody can say when one may be closed, so the queue fills with work that is neither being done nor allowed to end.
- Reopened tickets go back to the start and get the same documented fix applied a second time, and you need the chart to say where a reopen rejoins instead.
The CSV that produces this diagram
One row per step. The numbers in Line to are row numbers — that is what draws the connectors, and it is the column most files are missing.
| # | Shape | Box text | Line to | Line text | Horizontal lane | Vertical lane |
|---|---|---|---|---|---|---|
| 1 | Start | Submit a ticket | 2 | Raise | Requester | |
| 2 | Process | Record the ticket in the helpdesk queue | 3 | Raise | Service desk | |
| 3 | Decision | Enough detail to work the ticket? | 6, 4 | Yes, No | Triage | Service desk |
| 4 | Process | Ask the requester for the missing detail | 5 | Triage | Service desk | |
| 5 | Decision | Reply received before the chase window closes? | 6, 18 | Reply received, No reply | Triage | Service desk |
| 6 | Process | Set the priority from impact and urgency | 7 | Triage | Service desk | |
| 7 | Decision | Can first line resolve it? | 8, 11 | Yes, No, escalate | Triage | Service desk |
| 8 | Process | Apply the documented fix | 9 | First line | Service desk | |
| 9 | Decision | Did the fix work? | 15, 10 | Yes, No | First line | Service desk |
| 10 | Process | Record what was tried and hand the ticket over | 11 | First line | Service desk | |
| 11 | Queue | Assign the ticket to the specialist queue | 12 | Escalation | Service desk | |
| 12 | Process | Diagnose the fault and apply a fix | 13 | Escalation | Specialist team | |
| 13 | Decision | Fixed, or working around it? | 15, 14 | Fixed, Workaround only | Escalation | Specialist team |
| 14 | Process | Raise a problem record for the underlying fault | 15 | Escalation | Specialist team | |
| 15 | Tell the requester what changed | 16 | Close | Service desk | ||
| 16 | Decision | Does the requester confirm it is resolved? | 17, 11 | Confirmed, Still broken | Close | Requester |
| 17 | Success | Ticket closed | Close | Service desk | ||
| 18 | Reject | Closed, no reply from the requester | Close | Service desk |
#,Shape,Box text,Line to,Line text,Horizontal lane,Vertical lane
1,Start,Submit a ticket,2,,Raise,Requester
2,Process,Record the ticket in the helpdesk queue,3,,Raise,Service desk
3,Decision,Enough detail to work the ticket?,"6, 4","Yes, No",Triage,Service desk
4,Process,Ask the requester for the missing detail,5,,Triage,Service desk
5,Decision,Reply received before the chase window closes?,"6, 18","Reply received, No reply",Triage,Service desk
6,Process,Set the priority from impact and urgency,7,,Triage,Service desk
7,Decision,Can first line resolve it?,"8, 11","Yes, No, escalate",Triage,Service desk
8,Process,Apply the documented fix,9,,First line,Service desk
9,Decision,Did the fix work?,"15, 10","Yes, No",First line,Service desk
10,Process,Record what was tried and hand the ticket over,11,,First line,Service desk
11,Queue,Assign the ticket to the specialist queue,12,,Escalation,Service desk
12,Process,Diagnose the fault and apply a fix,13,,Escalation,Specialist team
13,Decision,"Fixed, or working around it?","15, 14","Fixed, Workaround only",Escalation,Specialist team
14,Process,Raise a problem record for the underlying fault,15,,Escalation,Specialist team
15,Email,Tell the requester what changed,16,,Close,Service desk
16,Decision,Does the requester confirm it is resolved?,"17, 11","Confirmed, Still broken",Close,Requester
17,Success,Ticket closed,,,Close,Service desk
18,Reject,"Closed, no reply from the requester",,,Close,Service deskHow it works
Start a new file rather than editing the export
Your helpdesk export has one row per ticket. The file you are about to write has one row per step, and there are about eighteen of them for a process that produced ten thousand tickets. Keep the export open beside you — the queue names, the priority levels and the assignment groups in it are the real vocabulary of your process — but write the chart into a fresh file. Trying to convert the export in place is the most common wasted afternoon in this whole exercise.
Write three columns: Shape, Box text, Line to
Those three draw a complete chart on their own. Put the header names on the first line exactly as spelled, one row per step underneath, and fill Line to with the row number of the next step counting the first data row as 1. Add Line text only where a row has more than one exit, and give it labels in the same order as the numbers in Line to. Everything else — lanes, styles, notes — can wait until the shape of the process is right.
Number the branches before you renumber anything
Line to is positional, so inserting a step in the middle shifts every row below it and silently invalidates every reference past the insertion point. Write the whole process out first, then fill in the numbers, then stop inserting rows. If you must add a step later, append it at the bottom and point at it from where it belongs — a chart does not care that its rows are out of order, and the arrows will still be right.
Save as UTF-8 with commas, and look at it in a text editor
Open the file as plain text, not in a spreadsheet, and check four things: the header row is on line one with no preamble above it, the fields are separated by commas and not semicolons or tabs, any label containing a comma is wrapped in double quotes, and accented characters look like themselves. A spreadsheet hides all four of these by rendering the file rather than showing it.
Drop the file onto the spreadsheet area
Import happens by dropping the .csv onto the editor's spreadsheet area, or by pasting the CSV text straight into it. Matching is by header name rather than by column position, so the order of your columns does not matter and columns the editor does not recognise are carried through and ignored. Leaving the original ticket id in a spare column is a cheap way to check your work against the export.
Set your chase window and your reopen route
Two values in this chart are placeholders for a decision only you can make. "Reply received before the chase window closes?" needs a real number of chases and working days, published to requesters. "Does the requester confirm it is resolved?" needs a rule for what happens when nobody answers, and a reopen that rejoins at the specialist queue rather than at first line. Write both into the Notes column so they travel with the file.
Frequently asked questions
What columns does a CSV need to become a flowchart?
Three: Shape, Box text and Line to. Shape says what kind of box the row draws — Start, Process, Decision, End, Success, Reject. Box text is the label inside it. Line to holds the row numbers this row connects to, comma-separated. Add Line text when a row has more than one exit, because a decision with unlabelled branches tells the reader that a judgement happens but not which way to go afterwards, and its labels are read in the same order as the numbers in Line to. Horizontal lane and Vertical lane are worth adding next, since they turn a chain of boxes into a grid of stages and roles. Line style, Parallel with, Notes and Link are decoration. Matching is by header name, not by column position.
My helpdesk export has one row per ticket. Can I import that?
You can, and you will get a column of unconnected boxes, one per ticket. The export is a record of instances; a flowchart is a description of the route those instances took. The columns a ticket export gives you — id, subject, priority, queue, assignee, opened, status — describe where each ticket ended up, and none of them names the step that follows another step. There is nowhere in that file for an edge to live. What the export is genuinely good for is vocabulary: the distinct values in its queue and assignment-group columns are your lanes, the distinct resolution codes are your endings, and a count of tickets per queue tells you which branch of the chart carries the volume.
Why does my imported chart draw boxes with no arrows between them?
Almost always because Line to holds something other than a row number. It is the target row's position in the file, counting the first data row as 1 — not a ticket id, not a step code, not the text of the next step's label. A value naming a row that does not exist is simply dropped, with no error and no warning, so a file where every reference is off by one renders as a field of disconnected boxes and nothing anywhere says so. The second cause is a delimiter that is not a comma: a semicolon-separated file, which is what many systems produce under a European locale, is read as one enormous field per line, so no header matches and no column is found.
Do I need Excel or Google Sheets to work with the CSV?
No, and there is a case for not using them. A CSV is plain text, so any text editor opens it and shows you what is actually in the file: the header row, the delimiter, the quoting, whether there is a preamble above line one. Spreadsheets render a CSV rather than showing it, which hides exactly the faults that break an import, and they also change files on the way through — reformatting anything that resembles a date, stripping leading zeros from reference numbers, and re-saving in whatever encoding they default to. If you do edit the file in a spreadsheet, check it in a text editor afterwards.
What are the stages of support ticket triage?
Five, and the chart above uses exactly those as its stage columns. Raise, where the ticket is submitted and recorded in the queue. Triage, where the service desk tests it for enough detail, chases what is missing, sets a priority from impact and urgency, and decides whether first line can resolve it. First line, where a documented fix is applied and checked. Escalation, where anything without a documented fix is assigned to a specialist queue, diagnosed, and either fixed or worked around. Close, where the requester is told what changed and confirms it. The two decisions people leave out sit at either end: a stated way for an unanswered ticket to close, and a reopen that rejoins at the specialist queue rather than repeating a fix that has already failed.