What’s Different about WEBCON, Part 1: They Did Stages Right
I’ll soon be adding content directly to WEBCON’s website, but I want to share a series of discoveries/observations I made on the way to joining them. If you’re familiar with Nintex or Microsoft Flow, this series of posts is about how WEBCON BPS is different (and often better) than those tools.
Some background on stages/state machines
For those of you that have simply used what SharePoint Designer 2013 calls “Stages” or what Nintex calls “State machines” without asking too many questions, we need a quick level set…
I won’t geek out too much, but state machine is a computer science concept that isn’t too hard to illustrate:
Consider a lamp with a pull chain. If it’s off, and I pull the chain, it’s going to be on. Pull the chain again, and the lamp is off. To diagram that as a state machine, it looks like this:
What’s important is that the lamp isn’t waiting for me to pull the chain. It will exist in a given state forever unless some event takes place. The two possible states here are Off and On.
We need an event to take place to cause a change in state. That’s a chain pull, in this case. There can be others, too, like the plug being pulled out out of the wall, the bulb burning out, the bulb breaking, etc.
The actual work is done in the transition between states. Transitioning between Off and On involves completing an electrical circuit, and transitioning between On and Off involves breaking that circuit.
So states, events, and transitions. That’s the language of state machines.
State machines are arguably easier to design and demonstrably easier to d monitor and audit. Oh, and they better reflect reality. But this isn’t about why state machines are good (I’ll write that article later). This is about how WEBCON BPS does them best.
A press release example
Let’s use a press release author-review-publish process as an example:
At any point, until it’s finished, the press release is being written/rewritten, reviewed by management, reviewed by the legal department, or being published. The arrows explain how to get from one state to another.
How others do it
Actually, many tools don’t attempt to implement state machine logic at all. We’ll stick with the ones that do.
Because I haven’t obtained permission to use actual screenshots of other products, I’ve created an abstract diagram that shows the essence of how some products would represent this kind of process. Have a look:
There are four things worth pointing out that are awkward at best:
- You need to be assigned a task in order to force an event (your decision) to take place. At all times, the workflow is still running and waiting for you to complete it.
- The diagram is laced with “go-to” icons. You need to jump around a lot. It’s not evil, but it can be clumsy.
- The state changes aren’t immediate. When you indicate what the next state will be (repesented by oval icons), the workflow won’t jump to the new state right away. If you have extra actions appearing after the Change State icon, they’ll be executed before the new state starts.
- See the extra Start and End icons, and the Stages section? In truth, this is really a sequential/linear workflow that has a state machine section in the middle of it. During my time at Nintex, I observed most people using their State Machine action as a way to have an interlude of quick back-and-forth interaction in the middle of an otherwise linear process.
Ultimately, the above isn’t an actual state machine. It’s a loop plus a switch plus a variable that emulates some of the behavior of a state machine. A more accurate diagram would be the following:
And in fact, if you wanted to emulate this in Microsoft Flow, this is what you’d have to do unless you (a) paid for Plan 2 of the Power Platform (to use a combination of Business Process Flows + Model-Driven PowerApps + the Common Data Service) or (b) used an even more complex diagram involving a set of Flows making recursive chained calls to each other over and over again, which would both be fragile (to put it kindly) and require paying for Plan 1 (Flow/PowerApps are nice, but let’s stop calling them being “free,” shall we?)
I’m not disparaging this approach. A lot of people, including myself, did good things with it. But there is a better way.
How WEBCON BPS does it
First, go back and look at the original diagram with five boxes and a few arrows. Now look at this:
It’s… five boxes and a few arrows! It’s really easy to follow, and it’s really easy to create. There are only two “extra” things going on here: (1) the Save&Continue action, which is a nod to the need to allow for saving/canceling changes while editing, and it provides a way to save without submitting, and (2) the little gear icons, which indicate that we have some work being done during those transitions named Submit, Forward, etc.
The transitions are where the work gets done. That’s where you indicate who will be asked to do what during the next state, whom to alert, etc.
The whole workflow is a true state machine. WEBCON BPS calls the state icons Steps and the transitions paths. The events are buttons automatically added to the UI; they could optionally also be web service calls, timer events, or the arrival of emails and/or documents in monitored locations.
Easy to design, easy to comprehend
In general, WEBCON BPS designs have far fewer icons. The setting of variables, the sending of alerts, etc. — all of the procedural stuff is relegated to configuration settings.
It means that when you see a diagram, you’re looking at what will (or can) happen. If you want to know how it happens, double-click on something to open it up.
Why this matters to you
As I said earlier, I’ll write something soon about why state machines are so important. What I will say is that this approach makes workflows easier to create, and more importantly, easier to change. In fact, WEBCON basically does everything on the assumption that you’ll be changing processes on a regular basis.
Actually, assumption has nothing to do with it. We know from decades of observation that process applications in particular (and nearly all applications in general) undergo regular change.
It also means that these are diagrams you can show users and business decision makers that they can actually understand. They are neither adherent to an academic design language that has a 250-page manual, nor are they cluttered with endless housekeeping steps.
It’s yet another reason to visit www.webcon.com and check it out. Or visit WEBCON’s booth at the SharePoint Conference in Las Vegas later this month. Or to download the Express edition of WEBCON BPS and use it to your heart’s content (it’s free — seriously).
More to come…
Other articles in this series
What’s Different about WEBCON, Part 2: A Process-Driven UX
What’s Different about WEBCON, Part 4: True Multi-Step Forms
