4 things to do before creating a workflow in SharePoint and Office 365

SharePoint and Office 365 provide you with a myriad of options to build workflows. From OOTB workflows to SharePoint Designer and Microsoft Flow, you have choices. With that being said, I suggest before you start using any of the tools, that you do proper analysis and prep work to make life easier for yourself. Let me explain.

I spent close to 20 years in the fields of Business Analysis and Project Management, and I must say that my education, background, and experience are invaluable assets when it comes to building workflows for my clients. The thing with workflows is that even simple business processes might require extensive analysis, requirement gathering, and of course, configuration.

A big mistake I see users make is that they start “coding” workflow in SharePoint Designer or creating actions and conditions in Microsoft Flow without first having a big picture of the process. To give you an example, a “simple” Purchase Order process with a user submitting a request and a Finance Manager approving might become a monster to create and configure If I start asking you the following questions:

1. Is it the same Finance Manager approving requests or different managers based on the employee/department?
2. What will be the logic for different Finance Managers approving the request?
3. What happens if Finance Manager rejects a request – will the user need to resubmit or create new request?
4. What happens if Finance Manager is on vacation – do we want to re-route/escalate the request to another manager or wait?
5. What happens if Finance Manager forgets to approve a request – do we want to send reminder emails? If so, how often?
6. Do you want to capture approval or rejection comments?
7. Is there a PO threshold for which a different approver (i.e. CFO) is required (example: POs > $10,000)

I can keep going and going, but I think you get the idea. We have to account for all of the above scenarios and eventually configure accordingly. So below I would like to give you few tips/ideas on how to properly do the prep work and document the process before you start configuring the tools.

Step 1: Spell it out

The best way to initially document the workflow is to spell it out.  Just type in the text as you discuss the workflow with your peers. For example, it might look something like this:

1. A user submits a request for a PO
2. Finance Manager gets an email notification with PO details
3. If Finance Manager rejects a request, an email goes out to the originator notifying him or her about the rejection. Manager can specify rejection comments, and those comments will also be part of the email to originator
4. If Finance Manager approves a request, the system then checks if PO is > $10,000.
5. If PO < $10,000, Finance Manager generates a PO Order and sends an approval email to originator with a PO #
6. If PO > $10,000, a request is submitted to CFO for an approval
7. If CFO rejects a request, an email goes out to the originator and a Finance Manager notifying them about the rejection. CFO can specify rejection comments and those comments will also be part of the email to originator and the Finance Manager
8. If CFO approves a request, an approval email goes out to a Finance Manager
9. Finance Manager generates a PO Order and sends an approval email to originator with a PO #

Step 2: Separate into Tasks, Emails, Actions

I call it a “TEA” method. We now need to separate above steps into Tasks, Emails, Actions (short for “TEA“). This will become handy later on when you have to convert this to visual diagram and actually create/build the workflow in workflow tools, like SharePoint Designer or Microsoft Flow.

TASK: An assignment to an individual to go and do something

For example, in the context of above Purchase Order example, once PO is approved, a Finance Manager would need to generate a Purchase Order #. This represents a physical task. Approve or Reject request for a Purchase Order could be another task.

For those who use SharePoint Designer, an action name for a Task would be either Assign a task or Start a task process

If you are using Microsoft Flow, you would be able to create a task in Planner using an action called Create a task

EMAIL: Notification message sent to a user

Email continues to be the primary business communication tool. As such, every time anyone needs to be notified about anything related to the workflow (status of approval, a request to approve) – an email is sent. Using a Purchase Order example, as PO goes through the process, participants get all sorts of email notifications (email with a request to approve, email with the status of the Purchase Order). Email can also contain important details about the item, like submitter info, item descriptions, etc.

For those who use SharePoint Designer, an action name for an email would be Email

 If you are using Microsoft Flow, you would be able to email using an action called Send an email

ACTION: Step that happens as a result of the workflow

When the Finance Manager approves a Purchase Order, the status of the submitted item (Purchase Order) changes from “Pending” to “Approved” via logic built into the workflow. This would be an action happening as a result of the workflow.

Likewise, Finance Manager might need to enter PO information into a 3rd party procurement system before a Purchase Order is generated. This too would be an action happening as a result of the workflow.

NOTE: If you are using Microsoft Flow, you might be used to a different use of terminology. An action in Microsoft Flow encompasses tasks and emails as well. In the context of this post/topic, the terminology I use for tasks, emails, and actions is unique since I use it to build a visual flowchart. So don’t be confused by the difference in terminology.

Step 3: Create a flowchart

Now the exciting part. Build a flowchart using Tasks, Emails, and Actions. You can use any tool, like Visio for example :-) . Use unique colors for Tasks, Emails, and Actions. Once all set and done, you might end up with a flowchart like the one below (click on the image to make it larger).

Connect the steps using arrows in a logical manner. You might also need to add conditions (“if” statements) depending on your process.

Step 4: Determine which actions happen outside of the workflow software

No, we are not done yet. Though we created a visual diagram, not all tasks, emails or actions will be driven by the workflow software. For example, Finance Manager might send some clarification emails outside of the workflow software to get some additional details about a Purchase Order Request. Or, to generate a Purchase Order, he may enter PO info into 3rd party procurement software. While these would be some definite tasks and actions for a Finance Manager and might be present in our flowchart diagram, they would not be documented or coded in any way within the workflow software. This Step is very important as this would “filter out” tasks, emails, and actions from our Visio diagram that we would not need waste time on within the workflow software.

Mark the corresponding boxes (tasks, emails, actions) that take place outside of the workflow software with a dashed border line, so it is clear which ones you do not need to code/build logic for. I already did this on in the image above, and you can see a couple of boxes with a dashed border.

That’s all! Now all you have to do is just choose your favorite Workflow tool. If you are on premises, you can utilize SharePoint Designer. For those of us who have SharePoint Online/Office 365, we can choose between SharePoint Designer or Microsoft Flow. Of course, I highly recommend Microsoft Flow.