Workflow Diagrams: Examples & Best Practices
A quick-start reference guide for anyone who wants to learn about visualizing, organizing, and optimizing processes, workflows, and tasks.
Common workflow diagrams examples
This page is all about workflows, what they look like, and the information they contain. You are in the right place if any of these statements apply to you:
- You or someone in your organization isn’t happy with the results of a current process or workflow, and you want to fix that.
- You need more control and insight into how work is getting done.
- You’re a citizen developer, and you’re the best person to solve a workflow problem for your team because you know the workflow and tasks as well as anyone.
You might also be a connoisseur of workflow diagrams or just workflow-curious. Whatever the case, the information here will make the trip worth your time.
Below, we will look at three detailed examples of common workflow diagrams: employee onboarding, procurement, and customer onboarding. We’ll also provide some best practices and try to answer some of the most common questions we hear from people who are diagramming their workflows.
|If you’re looking for information about flowchart symbols, workflow management, task automation, or general information on how to create workflows, we have that too. You can also find links to any of these topics at the bottom of the page.|
Example 1: Employee onboarding workflow
Diagram type: swimlane
In this example, the workflow has been illustrated as a swimlane diagram. This type of diagram is particularly helpful when the work (tasks, documents, information, etc.) moves back and forth between teams or departments. Here’s how it works:
The different actors that are involved in the process are listed on the left. In this case, we start with the recruiting team because they provide the trigger that starts the onboarding process by sending the signed offer to the Employee Training & Development Team (ETD). We want to make sure we are aware of that handoff between the recruiter and the ETD team.
The center of this diagram includes the 7 swimlanes. Each swimlane represents a particular team’s time, effort, and attention. As the work travels from team to team or person to person, its movement is tracked with flow lines and, in this case, icons to help us recognize the nature of the task at a certain point.
Finally, the column on the right lists the end results for each team. If and when these results are completed, then this instance of the workflow can be considered complete.
|Actors||Anyone or anything that holds the work. May be teams, departments, people, systems, or machines.|
|Swimlanes||Time, effort, attention, or other resources for a particular actor. Shows the movement of work between actors.|
|Results||The specific output or conclusion necessary for the workflow to complete satisfactorily.|
|FAQ: Do I need to use special symbols to create a workflow diagram?|
Answer: Not necessarily.
Your diagram needs to work for you and your team, so keep it as simple as possible. In some cases, you will want to use a set of standardized flowchart symbols to help people quickly recognize certain elements of the flow.
However, not everyone is familiar with the full library of standard symbols. For citizen developers and team members who are trying to map their workflows quickly, simple boxes for each step in the flow might work just as well.
Example 2: Procurement process
Procurement workflows can be complicated. That’s because the procurement process is really a family of related subprocesses that can include approving vendors, creating purchase orders, receiving goods, and paying invoices. Your procurement process may include other subprocesses as well, but these four are the most common so we will focus on them.
Diagram type: flowchart
As you can see, there is a lot going on in even a simple procurement process. That’s because the procurement process is really a family of four subprocesses that make up a procure-to-pay flow: approving vendors, creating purchase orders, receiving goods, and paying invoices.
|Best practice: Workflow diagrams can get quite large and have a tendency to sprawl, depending on the scope of the process and the amount of detail you want to provide. Before you illustrate your flow, consider whether or not you need to break your flow down into subprocesses.|
|Best practice: Make sure the subprocess name reflects the result you want. Alec Sharp recommends using the verb-noun format. For example, “approve vendors” is more precise and clear than “vendor approval process.”|
Example 3: Customer onboarding process
Diagram type: flowchart
As we saw with the procurement process example, some processes are actually groups of workflows that work together and are interdependent. In this case, we’ve identified six distinct workflows that must be completed in order for customers to be successfully onboarded.
|Best practice: When it comes to creating your workflow diagram, how you orient the flow is up to you. Depending on the complexity of the process and the tools you use to illustrate the workflow, you may want to create a horizontal or vertical layout. It is common for the action of a workflow to move from left to right, and top to bottom.|
Are there other workflow diagrams examples and types?
Yes, there are some specialized types of diagrams that may be useful.
In addition to swimlane diagrams and process flowcharts like the examples above, there are other ways to illustrate your workflows. These are SIPOC (an acronym for Supplier, Input, Process, Output, Customer) and BPMN (short for Business Process Model & Notation).
Rather than producing a dramatically different type of diagrams, SIPOC and BPMN are methods for standardizing the components, language, and formatting of workflow model illustrations. These methods may be more suitable for users approaching a workflow from a highly technical perspective.
Which type of diagram should I use?
Ultimately, the kind of diagram you create is up to you. A good digram should be useful, contain all relevant information, and be understandable to all stakeholders. In general, the simpler you can keep your diagram, the better.
In some cases, you’ll want to use a standardized set of flowchart symbols or create your diagram using a specific method for organizing and visualizing the process.
For many folks, a simple diagram that accurately represents all the actors (people, departments, systems, machines, etc.) and all of the necessary steps to produce a specific result will suffice. In some instances, the process leading up to the creation of the diagram will be extensive and require input from many stakeholders. These situations may produce more complex diagrams.
How much detail should I add to my diagram?
The more detail you can add to a diagram, the more insights you’ll have into how flows can be improved. However, one of the risks of diagramming work is that too much detail can bog down process improvement efforts.
As a starting point, ask yourself who is the audience for the diagram. If it’s business leaders who are interested in a 30,000-foot view of the process, it might be best to keep it simple and focus on the handoffs (places where the work moves between people, departments, or systems). If you need to really get into the weeds of a particular workflow, then you’ll want to map out each task in the flow and add additional context as needed.
It may also make sense to create multiple diagrams for a workflow, each with a different level of detail.