Tuesday, March 31, 2015

How to Develop Workflows Faster

This blog is the third in a four part series about how to make smarter, better, faster, and stronger workflows. Each post will focus on a certain area. In this post, I’ll discuss how to be faster with your workflow development.

With a solid technical design, workflow development will go faster. Even with the best technical design and mad workflow skills however, you may still be at the starting line of development wondering where's the best place to start.

Think of developing a workflow like building a house. First you need the foundation. And the foundation in a workflow is the logic. The logic, or as it’s sometimes called the business rules, define what the rest of the workflow can do.

Note: While I'm exclusively talking about workflow in these posts, it should be mentioned that building out your information architecture including content types and lists is essential before development of the workflow begins. In this context that's like making sure that the utility companies have run lines to your parcel of land and that you have all the permits you need before you start construction.

Building out your logic means typically means developing a bunch of IF THEN statements and defining the framework for which the workflow will operate within.

You can easily go crazy with a slew of IF THEN statements. To make it more complicated, if you have redirect actions - for example send a task back to the originator – it’ll look like spaghetti. There's a better way to handle this: state machines. State machines have the potential to make your development go faster. By eliminating, or rather changing how all the IF THEN statements are presented in the workflow, they'll make your workflow cleaner, which will make it easier to develop and sustain in the long run.

State machines are not a new concept. If you don't come from a programming background, here's a quick primer on workflow states. Not every process will require a state machine, but if you're dealing with any more than two business rules, state machines will most likely be your friend.

I believe that SharePoint is very democratic in that it allows anyone, regardless of their programming background, to make the most of the platform. Often it can be difficult to capture a state machine in a Visio diagram or a tech design – especially for folks who are new to the concept of a state machine. When this is the case, you're now at a point where the workflow being developed does not have parity between the workflow that was designed in earlier posts. This is ok. The end users/business owners don't necessarily need to know about this nor do they care. They only care that it works and the logic is being addressed correctly. The technical design serves as a guide to your development, but is not always the absolute source of truth. Even when building a home, something will come up that the blueprints do not account for.

With the logic stubbed out, you now have the wind to your workflow developing back. Let's keep the momentum going. Once you have the logic built, now is the time to bring in external data. If you have the data before you have the structure of the workflow to work with it, it can be a little overwhelming. But now that there's a foundation, you can start putting up some walls and running wires and installing pipe for the workflow. At the beginning of your workflow, use appropriate actions to get the data from SharePoint or other data sources into your workflow and set them as variables.

It's also good to validate that the data you're getting is correct and valid. If you need to clean up the data with a regular expression, now is the time to figure that out. I'll cover more about validation and how that can be done in my next post.

You already have the foundation and the walls. Now you need a roof. The roof would be the communications from the workflow. Do yourself a favor and write out what the emails should be either in your technical design, or another document. I've found that it's difficult to maintain consistency in the workflow when writing emails of all things. For example, in one action it can be called "Approval" and in another action it's "Action Required." Agree on the semantics and the communiques outside the workflow development tool. This way not only is it easier to find and correct any inconsistencies, but you have a bigger canvas to work with and not a small modal window. But do yourself a favor and don't work on these emails until the end of your development. Emails or other system messages are almost entirely cosmetic and are easy to change. Getting the logic and data will always take precedent over what communications the system sends out.

With the order of operations of workflow development now defined, you should be able to take your development from the starting line to being up and running in no time. The correct order of operations allows you to be faster with your workflow development and lets your focus your energy in a more productive manner. In my next post I’ll expand on what I introduced here and address how you make your workflow stronger.