Wednesday, April 8, 2015

How to Develop a Stronger Workflow

This blog is the fourth 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 create a stronger workflow.

Creating a stronger workflow closely follows creating a workflow faster. Being faster with your development doesn't mean anything if you workflow hasn't been tested. A well-tested workflow is a strong workflow.

There are several ways to achieve a stronger workflow and almost all of them can be done during development.

What I've found is best is to compartmentalize your development efforts - especially when it comes to business rules, or your IF/THEN statements. Once you’ve built out the framework, test every branch and every condition. Test every permutation of the logic to see how the workflow reacts. Only after you've validated that section of the workflow in its entirety, move on. It seems silly to build out a workflow end to end and save your testing to the end.

There's no shame in publishing a workflow early and often. You're laying the foundation here for the workflow and you want it to be firm and secure. The only way to validate the strength is to test. Once you've confirmed the logic is rock solid, then you can move on to another business logic action in your workflow. Once you've built out several, you can then test the business logic end to end.

All the major workflow products really don't allow you the ability to design or test the workflow from within their design canvas. This means that you're stuck wondering how the system is handling the data. Thankfully you can use the following actions to rapidly test and improve the strength of the workflow. If you're unsure about the condition or the data the workflow is dealing with don't hesitate to write to the history list, or send yourself an email saying "Hey this is true" or "Hey this is false." This way you can figure out exactly what the workflow is dealing with and validate that your logic is correct. Yes – you can fill up your inbox quickly this way, but I’d rather get 1,000 debugging emails than one nasty email from a client wondering why this bug wasn’t caught earlier.

Once you validate, you can either disable or remove these debugging actions. I like disabling them in the workflow so they are accessible should I need to troubleshoot later. But if you're working across multiple environments, be sure to remove any unnecessary actions before moving to a test or production environment.

One reason I'm such a vociferous supporter of publishing early and often is that when a project enters testing, test cases may either not be written at all or may not be written well allowing bugs can slip by which may lead to a production launch being stopped due to a bug that wasn't caught in testing, but could have been caught in development. I know it sounds like I'm talking about fire and brimstone here, but the fact is you can catch this early and ensure that the workflow is strong.

Another key component to a strong workflow is a good naming schema for variables. Here's why: if you win the lottery tomorrow and I inherit your workflow, I want to know what the heck is going on in the workflow. Variables named, "Eenie", "Meenie", "Miney" and "Moe" may make sense to you, but to me they may as well be Esperanto. A good naming convention is essential especially if you have several similarly named variables - as you don't want to accidentally use the incorrect variable by accident. There's no right or wrong way to name variables. I personally like to prefix my variables with the type, followed by an underscore and the variable name. For example, INT_ItemID, MLOT_ItemDescription, SLOT_ItemSummary. Whatever you use be consistent and be sure to document your convention. May I suggest documenting this in the tech design?

A workflow is only as strong as its environment. I've talked a lot about testing, but most of what I've discussed has been focused on testing workflow itself. When moving to another environment, you essentially reboot your testing efforts. If you've been following the guiding points through this series, you should know by now that your workflow is solid and pretty strong. To know that it's very strong, pivot your testing efforts to focus on configuration items.

A workflow has multiple components and the workflow itself is just one piece. Making sure that permissions are correct, users in the correct groups receive the proper notification, and that status columns are being updated correctly are just the tip of the iceberg. Depending on your workflow solution, you may also need to validate forms, content types, external data connections etc.,

While the items in the above paragraphs all are keys to a stronger workflow, the single best way to make a workflow strong is to run through different use cases as different users. Atticus Finch said that "You never really understand a person until you consider things from his point of view." That's true for workflow development too. You probably had God-like permissions in Development and maybe didn't have any test users. Now is your chance to test and see it from the perspective of the end user. Be sure that you have enough users to test and validate all the use cases.

The last piece to making your workflow strong is to test is your deployment strategy. When going to a new environment, have you created documentation about how to make it happen? Chances are that someone other than yourself might be doing the deployment, so make sure that your deployment instructions are accurate and can be easily followed.

Like any goal you set, achieving a smarter, better, faster, and stronger workflow won't happen overnight. But I believe that by following the guiding points I set out in this series of blog posts you now have the tools and the knowhow to smartly and effectively create some truly fantastic workflows that'll be transformative experiences both for you, your clients, and their organization.