There are many reasons why a SharePoint workflow deployment fails. It may be the cause of a bad process or end-user engagement during the project. Having no good communication commonly causes the failure as well. However, apparently people rarely realize that if the flow is complicatedly designed, it will damage the whole workflow deployment. For example, operation department in a company gave its IT team just a flow of the meeting room management and asked them to build the workflow for the company. The IT team then asked to clarify a few things before working out. Many weeks after then, the workflow went live but it had several problems and seemed not to be stable. Let’s look at the flow in more detail.
In many cases the responsibility of outlining flow is of business analyst, not only end-user. The flow above looks professional and seamless, but also quite complicated. Technically speaking, it would require developer to write event receivers in order to check availability of given meeting room. Take a look at another flow of the meeting room management below:
Obviously the latter is easier for developer to build the workflow. With the first flow, someone just selects date and time along with meeting room he needs to book for a meeting. The system has to check if the given meeting room is not available at the requested date and time. In this case, the check would effect the workflow performance. The workflow would get conflicted when running multiple checks at the same time as well. With the simpler flow in the 2ndexample, end-users can see which date/time and room are available, then they have to pick themselves on the visual calendar. There are actually no any activities running at the back-end to check the availability. End-user can’t select a confirmedly booked room if there is no priority rule based roles/group in the workflow. A common example is that if the request is a member of the management executive group, he can overwrite any current bookings but not confirmed.
State machine approach
Although in lots of real-world scenarios sequential workflows are used and helpful, it’s still a real nightmare for developers. Sequential workflow has steps that are performed sequentially. Technically speaking, the problem in this kind workflow is that you have no way to step backward. For example, if request of a proposal is submitted but requiring being further changed by reviewer, there is no way if using sequential workflow to assign revision task to requestor.
Imagine that a new workflow type that has events transiting among different defined states that represent the system. Yes, Microsoft does offer you that way to build such a more flexible workflow by Visual Studio.
When dealing with complex workflow with many sub-steps running independently, State machine approach is worth considering. Microsoft clearly defines components of a state machine workflow here.
If two approaches can be used for a given workflow, you need to make a decision which one is much easier to be built. Notice that state machine can’t be created and developed in SharePoint Designer. The template is only available in Visual Studio.
There are some ideas to make the design simpler:
- If a workflow has a calendar, it should allow end-user to themselves pick date/time. There are many common corporate processes that calendar is mainly used, such as Meeting room management, HR Interview Scheduling, Time Off management.
- If end-user can afford to check something rather than the system, let them do that. For example, someone has already known he can’t take 4 days off once. In this case, you would normally write an event to check the interval then notify submitter that he can’t have over 4 days off once. Instead, you could create a list that doesn’t include 4-day choice.
- Consider whether sequential or state machine approach. Each of them has pros and cons (i.e. state machine requires .NET and WF skills rather than sequential workflow people can build on SharePoint designer without having to write any lines of code.
Below are must-read references: