Developing JSLink SharePoint forms with workflows and associated issues – Part 1

I’ll start by saying I am not a fan of workflows, I find they generally introduce a lot of unnecessary problems, I much prefer to just develop a proper system with backend code and not some pointy clicky workflow BS.

However we can’t alway choose which technologies we develop a solution in, sometimes inappropriate technologies a thrust upon us from above.

I am a fan of JSLink though and in my opinion it’s a much better  forms solution in SharePoint than InfoPath ever was, I have seen some truly horrifying InfoPath forms in my time and I have been trying to talk people out of using InfoPath for years so I was very happy the day it was announced that InfoPath was deprecated.

Anyway I’ve developed a few solutions using JSLink and various workflow technologies now, so I’ve decided to write a bit about some of the approaches that I have found to work quite well, I’m going to break this up into a number of articles and the first topic will be how to handle workflow tasks.

How to handle with workflow tasks

So one approach I’ve found works is instead of directing the user to the workflow task, direct them to the form for the item the task is related to (the original list item), then once the user has done what they need to do in the original item complete the workflow task via a REST web service call.

Now when you use this approach it is important that you save the original list item before you complete the task items otherwise you will get save conflicts, and this is because when you complete the workflow task it will fire up the workflow which will then alter the item you are working on.

This is where it starts getting tricky, when you save the list item you will automatically get redirected to either the list view or the “Source” url preventing your from making the necessary REST calls to complete the workflow task.

So to get around this we need to override the default redirection behaviour of the form which works like this:

Once you have overridden the default redirect behaviour and saved the form your can now complete the workflow task like this:

Note: I have not included querying of the tasks list to find the associated tasks, you will need to do this to get the id of the associated task, in my example above I have hardcoded this id as 1.

Using this approach I find is much more intuitive for the user, and we are not using the workflow task to collect information from the user we are simply using the task to indicate that there is action required of the user, any data that is collected from the user is captured in the original list item where it is needed.

Note: In these examples I have not given much consideration to code structure and method breakdown, however these are very important elements of any application, and you should give careful consideration to this when developing your applications.