My grandfather is a carpenter and if there's one thing I've learned from him it's to measure twice and cut once. When developing workflows on SharePoint, you need to measure at least twice. But how and what do you measure? When developing SharePoint workflows, regardless of the workflow platform, I've often seen it where development begins immediately after the workflow is mapped out as a gorgeous Visio process. I really appreciate the fact that we're all eager to automate pain points but jumping to development after mapping out the process is a one-way ticket to development issues later on. In this post I'm going to detail how to create a workflow technical design.
Completing a technical design should be done for any workflow before development starts. A technical design is the blueprint that you, the developer, will take and turn a gorgeous Visio process into a gorgeous workflow. To return to my grandpa’s aphorism, we're going to measure twice by making sure this technical design crosses all of the "t"s and dots the lower case "j"s of SharePoint workflow development.
This post is catered to SharePoint Designer workflows, and specifically task process. There's a lot out there on task processes. While it may seem very 2010 to talk about task processes, the fact is they're still around in SharePoint 2013. So before we proceed to give you what you need, if you haven't already, read up on my coworker's Kim Frehe's essential reading SharePoint Designer 2010 Workflow Advanced Properties and SharePoint Designer Workflow 2010 Task Actions. Once you've done that, read them once more to let it sink in, and then return here.
Since I'm limited with the formatting on this blog, I've made the workflow technical design as a Word doc. Because I care about you and your tech design, in the document I've done my best to explain what each section is for and I’ve left some examples for you in each section as well.
Happy Workflow Tech Designing!