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.
After I gained a bit of experience with Workflow, I began to attempt to tackle more complex processes. While developing these, I ended up with a sprawling mess of a canvas, duplicate evaluations and actions, and path lines jumping all over the place and each other. It was at that point that another, more experienced Workflow developer showed me the importance of modular processes, how to configure them, when to use them, and the difference between model types.
First helpful rule: if using the “fit to screen” zoom button renders the Workflow tiny and indecipherable, then you could likely benefit from some linked or embedded models. We’ll go over the different types shortly.
Second helpful rule: the easiest way to simplify the sprawl of a workflow is to group components into Embedded Rule Model components. Embedded Rule Models are like using folders to sort a stack of random documents on your desk into a nice, neat filing system.
Buried in this process are way too many static values (not to mention that this screenshot will be a great illustration for my “Making Modular Workflows” article I’m working on).
When I first started developing Workflows, especially processes that integrated with other systems (SQL in particular), I would occasionally run into this:
“Hi Andrew, we need to move the SQL server you’ve integrated with. Here’s the new connection info. Hope it’s not a big deal. You declared your connection string variable up front, right?”
Oops. Well, dozens of components buried in layers of embedded models later, I had updated all the SQL components. Except this time, I used a project property. The next time the SQL connection string needed to change, I updated a single value, published, and enjoyed the success.