Have a look at two examples of sprawling processes, and imagine trying to make sense of them. The first I can take credit for; the second, I can only take credit for grabbing a screenshot when I saw it.
Let’s take a look at how to keep a readable, usable Workflow canvas, and untangle that spaghetti.
Rectangles and description components (Annotation, Sizeable Annotation, and Rich Text Annotation) are exceptional for helping keep our workflow readable. You’ll notice that in the first example (above), I’ve begun to use annotation and rectangles to help separate some of the components into process groups. Here’s an example of where this fits.
In this illustration, the three main sections have been clearly separated by colored rectangles, and named with annotation labels.
Annotation can also be useful for documentation purposes, even to the extent of brief descriptions of each step of the flow:
Grouping Components Into Models
Implied Data Flow
Here’s a tip to remember: component connector lines are not always required in order to get from one component to another.
There are several components we can use to replace the connector lines we thought we needed — the ones that are jumping all over one another trying to get to their destinations. Let’s cover Go To Component By Name and Hanging Path Trigger By Path.
The key difference (although not exclusive factor) when deciding between the two components is that the hanging path can be used on exactly that – a component’s output path. What if we need to send data somewhere else on our canvas from a component that has no named output path? We can’t grab it with a hanging path component, so we’ll use a go-to component after it instead.
There are times at which implied data flow with triggers and go-tos aren’t possible. For those situations, we can use Single Path Demo components to make the best of it.
For example, take another look at the first illustration in the Annotation/Documentation section above. You’ll notice the use of “Tether” components that are keeping our lines pulled in the direction we want, and out of the way of other components and lines on the canvas. Think of it as cable management for your connector lines.
Demo components can be used as adaptation buffers as well. As an example, let’s say we have 36 components all leading to the end component in a model. Now, what happens if we determine during testing that we need to add one last component before the end component? 36 lines have to be redrawn to the new component, and then the new component to the endpoint. However, if we use a demo component as a tether instead, we then have a buffer between the endpoint and our 36 lines.
I Informed You Thusly – Variable Persistence
When using methods that circumvent the normal connector lines for data flow, model-scoped variables may not be available after the jump. Have a look at this illustration:
In order to grab the variables that were lost, we’ll use a Variables Exist component and select which variables we want to pick up from the model’s available variable list.
Here’s an updated model.
Even though we have no direct connector lines to the endpoint, the variables have been plucked from the air by the Variables Exist component, and are now available.
What About Swimlanes?
It’s solely my own personal preference and opinion that swimlanes are both cumbersome and unappealing, so I don’t use them. That’s not to say that they’re not useful in some way, I’m just not a fan.