What is a flowchart used for? Twelve real jobs

A flowchart earns its keep on a decision. If you are asking what is a flowchart used for, the practical answer is the twelve jobs below: support triage, hiring, incidents, checkout, approval, onboarding, deploys, billing exceptions, data fixes, a classroom, an audit, and the private branch you draw while drafting. I open one when a yes or no changes the next step. I pick another diagram when the picture is a conversation between services or a map of tables.

The boxes are steps. The diamonds are questions the team already asks out loud. The arrows are the only legal next moves. When a Slack thread re-decides the same branch every week, the missing artifact is usually this picture, sitting next to the policy, updated in the same change. The guide to creating a flowchart in Mermaid is the syntax. This page is the reason you would bother to learn it.

You do not need twelve drawings. Three of these jobs are drawn later, because they are the ones I get asked to paste into a runbook. The other nine are uses I would still open a file for, written as the paragraph I wish someone had put above the chart.

Twelve places a flowchart actually helps

Support triage

Support triage is the flowchart I have redrawn most, and the one teams still try to replace with a mood in the help center. A ticket arrives. Someone decides whether the customer is blocked, whether a workaround exists, and whether engineering should see it tonight. Those are diamonds. A chart that starts at "empathize" and finishes at "resolve," with no question in the middle, cannot triage. It can decorate a wiki. Write the questions the way the on-call asks them on a bad afternoon. "Customer blocked?" is a question. "Provide excellent support" is a poster. If the blocked path pages a human and the other path waits for the next shift, draw the wait. People delete the wait because it looks unimpressive, then new hires page engineering for a typo.

Hiring

Hiring is a flowchart whether or not the company calls it one. A resume arrives, a screen happens, a loop happens, an offer goes out, or someone says no. I draw this when interviewers disagree about who is allowed to reject, which is a policy problem wearing a scheduling hat. The useful diamond is "Did the hiring manager see the work sample?" A diamond labeled "culture fit" is useless until the chart says what evidence that decision uses. The mistake I keep seeing is a chart of only the success arrows. Every stage looks like progress, and the no is a footnote. Candidates and interviewers then invent their own no. Put the rejection on the chart. It can land on one box, "send the decision." You do not need a unique speech for every stage. Twelve rejection boxes is how these charts rot in a drive somewhere.

Incidents

Incident response is a flowchart for the first minutes, and a timeline after that. The chart should answer who is the lead, whether you mitigate before you explain, and when you stop treating the page as an incident. I have watched a team paste a twenty-box responsibility grid into the incident channel while the error rate climbed. Nobody read it. A short chart with one loop, mitigate until the graph is stable, beats a taxonomy of severity colors nobody can recall under pressure. Draw the acknowledgement as a step. If users are affected, name a lead. If they are not, draw the watch path so people do not escalate out of guilt. A diamond that only says "Is this a SEV-1?" starts a second incident, the argument about the number, unless the arrows carry the definition you actually use.

Checkout

Checkout is the flowchart product and finance already share in their heads, and rarely write down until a launch week fight. Cart, payment, stock, shipment, receipt. The branches that matter are the ones that lose money: the card is declined, the item is missing, the carrier will not take the address. I would rather see those diamonds than a happy path that assumes the card works because the demo did. A single box called "Payment" hides the retry, and the retry is the product. If the customer can offer another card, the arrow comes back to the question. If they cannot, the arrow leaves. Those are different checkouts. Draw the one you shipped. Leave the kickoff-doc version in the kickoff doc.

Approval

Approval chains are flowcharts, and they go stale the week a director is on leave. Request, manager, finance, recorded decision. The value is showing who can send the work back, and whether "back" means the author or the previous approver. I draw this when two people both think they are the last signature. Skip the org chart. Encode the decision. If any manager in the department can approve under a threshold, the diamond is the threshold and the box is "a manager," which you can explain in the paragraph. Names live under the figure, where you can edit them without retouching every arrow. The user login flowchart template is the same kind of policy, written for a sign-in screen, if you want a software cousin next to a finance one.

Onboarding

Onboarding is a flowchart for the part that can fail. Account created, access granted, laptop delivered, first task assigned. I leave the welcome lunch off. Draw the gates: can they push a commit, can they read production logs, who approves the extra permission. A new hire will follow arrows. They will not infer a missing access request from a box that says "get settled." I also keep a private version of this when I join a team. It is for me. I want to see which step is blocked on me and which step is blocked on someone with a calendar. If every box is mine, I have drawn a todo list and given it a process costume.

Deploys

A deploy flowchart is the release policy. Build, test, canary, promote, or roll back. I want the rollback arrow visible, because a chart that only points forward is how a team talks itself into fixing forward on a day the policy says roll back. The diamond is whether the check is healthy. The labels on the arrows are the policy, in the words the pipeline already uses. Skip a box called "platform magic." If a human clicks, the box names the human step. If CI does it, the box can name the job. The chart is allowed to be boring. Boring is how you notice that production and the canary do not share a check, which is the sort of thing a status meeting will sand over.

Billing exceptions

Billing exceptions are where a flowchart pays the rent. A charge fails, a refund is partial, a tax rate is missing, a coupon stacks when the code says it must not. Support and finance will each invent a path unless the chart says which path is real. Draw the exception. The happy invoice is a straight line and does not need a poster on the wall. The mistake is one diamond that mixes the customer's question with the ledger's question. "Should we refund?" is policy. "Did the ledger already settle?" is data. Mash them together and the chart approves a refund the books cannot post. Split the question. Your future self, reading this during a close, will spend the hour on the customer instead of on the chart.

Data fixes

A data fix is a flowchart you write before anyone touches production, then you attach it to the ticket. Read the row, decide whether it matches the bug, write the change, check the count, stop. The diamond that matters is whether this row matches the ticket. The arrow you must keep is the stop, taken when the count is wrong. I have seen a one-box chart that says "update the table." That is a wish with a border. The useful chart says who runs the change, what they compare, and what they do when the compare fails. If there is no compare, you do not have a fix yet. You have a rectangle around a hope, and production is a bad place to discover that.

Classrooms

In a classroom I use a flowchart to make students argue about a branch. A small process they already know, returning a book or resetting a password, is enough material. The point is the diamond. Ask which question is missing. They find it faster on a chart than in a paragraph written at midnight. Handing them a twenty-node chart from a real company and calling it an exercise teaches copying. Start with four nodes. The template library has longer examples when the class is ready to set a toy next to a real login flow. Until that week, short is the assignment, and a student who can defend one diamond has learned the tool.

Audits

An audit flowchart is a control, drawn so someone can point at a step and ask for evidence. Who approves, where that approval is stored, what happens if it is missing. I draw this so the team can see the step we claim and the step we do. If the chart says "manager sign-off" and the ticket system has no field for it, the chart is a finding you wrote yourself, which is embarrassing and useful. Keep one control on each chart. A single diagram of an entire compliance program is a mural. People do not review murals in the week the evidence is due. Name the evidence box with the words your tracker actually uses, or the auditor and the engineer will nod at different systems.

Personal writing

I use a flowchart on my own drafts when a doc has two audiences and I keep blending them. "Is this for the on-call, or for the new hire?" sits at the top of the file until the prose can stand alone. It looks a bit silly in a commit. It works at 11 p.m. The chart is a note to myself, and it is allowed to be deleted once the pages split. The mistake is polishing that private branch into a diagram the team must maintain. If you commit it, you now have a second source of truth. I would rather keep the scratch chart in the editor and let the doc be the artifact, unless the branch is a real policy someone else has to follow on a weekend.

Triage, drawn so a new hire can follow it

The flowchart syntax reference covers shapes and edge labels. The figures here stay short on purpose. A node is a label, and the paragraph under the figure carries the rule that will not fit in the box.

This is the triage path I would paste into a runbook. Both the page and the wait come back to the same workaround question, because "done" should mean one thing.

flowchart TD
  arrive[Ticket arrives] --> blocked{"Customer blocked?"}
  blocked -->|Yes| page[Page on-call]
  blocked -->|No| wait[Leave it for the shift]
  page --> known{"Workaround exists?"}
  wait --> known
  known -->|Yes| send[Send the workaround]
  known -->|No| hand[Hand to engineering]
  send --> closeBox[Close or follow up]
  hand --> closeBox

I named the last node closeBox on purpose. The id end is a Mermaid keyword. The moment you wrap a region in a subgraph, a node called end closes that region and the rest of the file falls out of the picture. Ids are handles. Labels are the words humans read. You can label a box "Done" while the id stays closeBox.

Read the join. If the wait path never meets the page path, you have drawn two teams by accident. I have done that, shipped it, and then spent a standup explaining why "follow up" meant something different for a paged ticket than for a queued one. The join is the sentence the chart is for.

Checkout, including the second card

The retry is the whole reason to draw checkout. A straight line from cart to receipt describes the demo. It does not describe Tuesday.

flowchart TD
  cart[Cart is ready] --> paid{"Card accepted?"}
  paid -->|No| other[Ask for another card]
  other --> paid
  paid -->|Yes| stock{"Item in stock?"}
  stock -->|Yes| ship[Create the shipment]
  stock -->|No| hold[Hold and email]
  ship --> receipt[Send the receipt]
  hold --> receipt

The arrow from "another card" back to the diamond is a product decision. If your checkout does not allow a second attempt, delete that arrow and send the refusal somewhere honest, such as a cancelled order and a message. Leaving the loop in because an example had it is how docs drift from code. An example is a starting shape. Your policy is the edit.

Stock and payment are separate diamonds. I once combined them into "Can we fulfill?" and support could not tell a declined card from an empty shelf. Those calls need different scripts. Two questions take more vertical space. They save the wrong email.

The first minutes of an incident

This chart stops when the timeline starts. It is not a postmortem, and it will lie if you hang every communications task on it.

flowchart TD
  alert[Alert fires] --> ack[Ack the page]
  ack --> users{"Users affected?"}
  users -->|Yes| lead[Name an incident lead]
  users -->|No| watch[Watch and write a note]
  lead --> mitigate[Mitigate]
  mitigate --> stable{"Stable?"}
  stable -->|No| mitigate
  stable -->|Yes| timeline[Write the timeline]
  watch --> timeline

The loop on mitigate is small and deliberate. "Stable" needs a meaning in the paragraph under the figure, or the loop becomes a place to hide. I write that meaning in the runbook sentence, not in the node. A node that says "Stable according to the dashboard, the canary, and the support queue" becomes a column of wrapped text and the arrow into it looks lost.

If users are unaffected, the watch path still ends at a written note. Skipping the note is how a quiet alert becomes a surprise at the next one. I would rather have a dull box than a gap.

What I leave off on purpose

I leave a flowchart alone when the story is a sequence of calls. "The app asks the bank and the bank answers" has speakers and an order. A flowchart flattens the speakers into boxes and the order into a vibe. Use a sequence diagram for that conversation. I also leave flowcharts alone for a data model. Boxes that are tables, with arrows that are foreign keys, get misread as steps in a process. When the arrows are data moving between people, processes, and stores, the data flow diagram generator post is the closer read. Mermaid still has no separate DFD type, so that post builds the picture out of flowchart shapes on purpose.

I do not number nodes 1, 2, and 3 as their ids. Renaming a step should change a label. Teams that use the sentence as the id produce a diff that touches every edge, and the reviewer cannot see the policy change inside the noise. Color waits until the chart is true. A green success and a red failure can help a runbook. Five colors ask the reader to decode a legend before they are allowed to follow an arrow.

Direction is a reading order, and I pick it once. Top to bottom fits a decision that falls through questions. Left to right fits a pipeline that hands work sideways. Mixing them inside one chart, without a subgraph that owns the change, is the fastest way to make six nodes look like a maze. If I cannot explain why a subgraph exists, I delete the box and let the arrows speak.

How these files go stale

A flowchart nobody updates is worse than a missing one, because it still looks official. Put it in the same change as the policy. The triage chart belongs in the runbook pull request. The deploy chart belongs next to the pipeline, or in the doc the pipeline links to. A slide is a snapshot. Date it if you must export one, and keep the text as the source.

The flow charts post and the note on what flowcharts mean sort out words people mix up in reviews. Making a flow chart is the construction side, the part about sitting down and producing the figure. I am staying on the uses, because the usual failure I review is a tidy chart of the wrong job. The syntax was fine. The diamond was a slogan.

Two copies will diverge. The wiki and the repo do not share a secret sync. Pick one home. I have updated the wiki during an incident, left the repo stale, and quoted the stale file a month later with great confidence. It felt efficient that night. It was a bug with a nice rendering. If legal needs a picture in a packet, export from the source that day and write the file name under the figure.

Labels rot when they quote a threshold that finance changes in a spreadsheet. "Over 50" is a fine label only while 50 is the rule. When the rule moves, the chart moves in the same pull request as the constant, or you accept that support will follow the picture and the code will follow the spreadsheet. I have lost that argument in both directions. The chart does not win by being prettier. It wins by being the file someone had to touch.

Start from the argument you already have

Start with the use that already causes arguments. For most product teams that is checkout, approval, or triage. A poster of the whole company can wait. Paste the closest chart from this page into a live preview, and rename the diamonds until they sound like your team on a weekday. The preview updates as you type, so a bad arrow shows up while you still remember why you drew it. No account is required for that loop.

If the chart grows past a screen, you probably merged two uses. A hiring chart and an onboarding chart can mention each other in prose. They should not share a canvas because both involve people. Split them, keep the ids boring, and let the next person change a label without fear. That is the whole practice. The twelve jobs are just twelve places the practice pays rent. Open the editor and draw the one your team is already arguing about.