Flowchart examples give you reusable paths for an online order, a leave request, login recovery, an API exchange, and a repeated calculation.

Fill-in key: put an action such as [Pack item] between vertical connectors, a question such as <Payment approved?> at a branch, and a named outcome at each endpoint. The examples below contain those labels already, so you can adapt a complete path instead of guessing what belongs in a blank.

In This Article

• Read the Symbols Before Following a Path
• Follow an Online Order From Checkout to Delivery
• Show Who Handles a Leave Request
• Reset a Forgotten Password
• Trace an API Request and Its Response
• Turn a Repeated Calculation Into Program Logic
• Key Takeaways
• Frequently Asked Questions
• Start With One Clear Process

Read the Symbols Before Following a Path

The flowchart symbols tell you what kind of text to supply. An oval or rounded rectangle marks a start or end; name the event or result inside it. A rectangle holds an action, so use a verb and its object: “Authorize payment,” not “Payment.” A diamond holds a question whose answers label the outgoing arrows. A parallelogram commonly represents input or output.

The text diagrams use parentheses for endpoints, square brackets for actions, and angle brackets for decisions. Slashes mark input or output. Arrows establish direction; they do not replace action boxes.

For a custom box, replace [Step Name] with the work performed at that point. Replace <Decision Question?> with a condition someone can answer, then give each outgoing arrow a distinct answer. “Yes” and “No” suit a two-way question; named outcomes suit a choice with more branches.

Choose the layout after identifying the question. A basic process chart explains sequence, while swimlanes add responsibility. A data-focused chart follows information between participants; a programming chart exposes conditions and repetition. These categories overlap. Each example below identifies a boundary, supplies a connected path, and shows which labels you should adapt.

Follow an Online Order From Checkout to Delivery

This flowchart example starts when the customer submits an order and ends at delivery or a checkout failure. The sample store checks stock before authorizing payment. Replace the action labels with your store’s actual fulfillment steps, keeping the failure branches attached to the checks that trigger them.

(Start: customer submits order)
              |
              v
    <Stock available?> --No--> [Show unavailable] --> (End: unavailable)
              |
             Yes
              v
     [Authorize payment]
              |
              v
   <Payment approved?> --No--> [Show payment failure] --> (End: unpaid)
              |
             Yes
              v
         [Pack order]
              |
              v
         [Ship order]
              |
              v
[Receive carrier delivery confirmation]
              |
              v
   (End: order delivered)

Here, “Payment approved? No” means the authorization attempt was rejected. That condition triggers the unpaid-order branch; a customer merely reaching checkout does not. An unavailable item never reaches authorization, and a rejected payment never reaches packing.

The two messages therefore need different wording: one concerns item availability, the other payment. Preserve that distinction when renaming the boxes. The delivery confirmation represents the carrier reporting delivery, not the store assuming that shipment means arrival.

Among process flowchart examples, this one makes scope easy to adjust. For delivery-delay analysis, expand packing and shipping into the relevant operations. For checkout eligibility, combine them into “Pack and ship.” Returns and refunds remain outside this chart’s boundary.

Show Who Handles a Leave Request

Use this template when the question is “Who acts next?” The employee supplies dates, the manager decides whether coverage permits leave, and the HR system records an approval before the employee receives it. These are sample policy rules, not requirements for every workplace.

Employee                 Manager                    HR System
   |                        |                           |
(Start: leave needed)        |                           |
   |                        |                           |
   v                        |                           |
[Submit dates] --------> <Coverage available?> --Yes--> [Record approval]
                            |                           |
                            No                          |
                            v                           |
[Receive rejection] <-- [Decline request]                |
   |                                                    |
   v                                                    |
(End: declined)                                          |
                                                        |
[Receive approval] <-------------------------------------+
   |
   v
(End: approved)

To customize the lanes, replace each column heading with an actual role or system, then keep its actions beneath it. The manager’s decision must not drift into the HR system lane: recording a decision and making it are different responsibilities.

For each crossing arrow, fill in “sender: ___; information passed: ___; receiver’s next action: ___.” The submission handoff carries requested dates to the manager. The approval handoff carries the decision to the recording system. If an approval is recorded but never reaches the employee, examine the notification handoff.

Add leave-balance checks or conflicting policy rules only where they apply, assigning each to its owner. An unexplained wait after submission should have an owner too.

Reset a Forgotten Password

This recovery path begins when someone has forgotten their password. It includes a return path for an expired reset link and an explicit error state for a sign-in that still fails after the password changes.

(Start: password forgotten)
          |
          v
 [Request reset link] <----------------+
          |                            |
          v                            |
  [Open reset link]                    |
          |                            |
          v                            |
   <Link expired?> --------Yes---------+
          |
          No
          v
 [Set new password]
          |
          v
   [Retry sign-in]
          |
          v
 <Sign-in succeeds?> --No--> [Show sign-in error]
          |                            |
         Yes                           v
          v                     [Contact support]
  (End: signed in)                     |
                                       v
                                (End: escalated)

Keep “Request reset link” as the expired-link loop’s destination. Reopening the expired link would not change the condition. If your recovery procedure uses a different action, name the action that produces a usable replacement.

“Show sign-in error” gives the support branch a visible failure state. Replace that label with the message your procedure presents, without inventing a diagnosis: a failed retry after a password change does not establish the cause. Support marks the limit of self-service recovery.

Use conditions the reader can recognize, such as “Link expired?”, instead of an internal authentication code. A troubleshooting decision should tell the user which arrow to follow.

Trace an API Request and Its Response

The shipping-quote template names both the incoming payload and the outgoing result. Its sample fields are destination and package_weight; replace them with the fields your service requires, and make the validation question match those requirements.

   (Start: client needs shipping quote)
                    |
                    v
/Send payload: destination, package_weight/
                    |
                    v
        <Required fields valid?>
             |              |
             No            Yes
             v              v
 [Return HTTP 400]  [Calculate shipping quote]
             |              |
             v              v
[Client shows error] [Return HTTP 200 with quote]
             |              |
             v              v
 (End: correction   [Client displays quote]
      needed)               |
                            v
                   (End: quote available)

In this example, the payload is parseable JSON; the decision concerns the required fields. HTTP 400 represents the invalid-request outcome, while HTTP 200 represents success. Keep “with quote” in the success label: a response code alone does not identify what the client receives.

The client’s next action completes each branch. An error leads to correction; a successful response leads to displaying the quote. When adapting the chart, name what the client does with your response instead of ending at “Return.”

This control-flow view follows decisions in an information exchange. A formal data flow diagram instead emphasizes information moving among processes, external entities, and data stores. Add timeouts and retry limits for a reliability question; expand acceptance rules for a validation question. Let the question determine the extra boxes.

Turn a Repeated Calculation Into Program Logic

A programming flowchart makes initialization and progress visible. This sample totals purchase amounts using an index to select each entry. The initialization box supplies the values needed before the first decision.

                (Start)
                   |
                   v
        /Read list of amounts/
                   |
                   v
     [Set total = 0; index = 0]
                   |
                   v
  +--> <index < list length?> --No--> /Output total/
  |                |                          |
  |               Yes                         v
  |                v                (End: total calculated)
  |  [Add amounts[index] to total]
  |                |
  |                v
  +---- [Set index = index + 1]

Trace the sample list 12, 8, and 5: after all three entries, the output is 25. Then trace an empty list. The first condition is false, so the output is the initialized total without entering the loop.

The index update explains why the loop finishes. Without it, a nonempty list repeatedly adds the same amount because the continuation condition never changes. When adapting the chart, name both the repeated action and the update that advances it.

The inputs here are valid numeric amounts. Typed text or imported records may need validation, and financial software needs an appropriate representation for money. Those implementation choices deserve their own detail when they affect the calculation being explained.

Key Takeaways

• Replace sample labels with language the person performing the work recognizes; each action should name work with a verb, not leave an unnamed step on a connector.
• Give each decision an answerable question and distinct, labeled exits that match it.
• Use lane ownership to expose missing handoffs, identifying what reaches the next owner.
• Make loops change something before they return to a decision.
• Name the result reached at each endpoint.
• Test an ordinary case and an exception with someone who performs the work before reusing the structure.

Frequently Asked Questions

How do I create a simple flowchart?

Create a simple flowchart by naming its start and finish, then connecting the actions and decisions between them. Replace [Step Name] with a verb-led label. For each decision, complete “question: ___; possible answers: ___; destination for each answer: ___.”

What are the four main flowchart types?

One common grouping is process flowcharts, workflow diagrams, swimlane flowcharts, and data flow diagrams, although no universal set of four exists. Choose by the question you need answered, since these categories overlap. Data flow diagrams use different conventions, so do not automatically copy decision diamonds into one.

What is a flowchart?

A flowchart is a diagram of connected symbols showing steps and decisions in a process. Its labels should let a reader act: “Payment approved?” supports “Yes” and “No,” while “Payment” leaves the branch rule unstated.

How should a beginner decide how to make a flowchart for an existing process?

A beginner deciding how to make a flowchart should first identify the question it must answer and observe the relevant work. Ask the people doing it to supply actual action names and decision conditions. Keep current practice separate from proposed improvements, then trace a real case through the labels.

When should a process use swimlanes instead of a basic flowchart?

Use swimlanes when changes in responsibility affect how readers understand the process. Validate each handoff with “sending role: ___; item passed: ___; receiving role: ___; next action: ___.” If one person handles the whole procedure, a basic chart usually avoids unnecessary lane structure.

Start With One Clear Process

Run one actual case through those labels with someone who performs the work. Repair missing actions before adding visual polish, and keep only detail that changes the reader’s next step. Remove any decision diamond whose answers lead to the same action without changing the process.