SharePoint Developers and Architects are often faced with a dilemma on what tool to use for SharePoint based workflows. OOTB workflows are usually only meant for very simple workflows and most often there are customizations involved with most Enterprise Workflows. The best way to save customers time and money is to find a way to leverage OOTB tools such as SPD.
In this blog post, I explain the limitations of using SPD Workflows. Hopefully this post will help you realize what you cannot do OOTB and find workarounds for existing limitations of using a SPD Workflow.
Advantages of using SPD are already well known: no code, declarative in nature, lots of OOTB actions and decisions, easy to maintain and deployment across different environments by exporting the workflow as a wsp.
Mentioned below are problems/issues we faced and workarounds for those issues:
- Limitation on the number of approvals: There are issues with publishing the workflow after about 6 approval steps. If your workflow has more than 6 approval steps consider a custom WWF workflow or evaluate third party products such as Nintex/K2. Once we realized this issue, we had to convert a few approval tasks to Collect Data Tasks as a workaround, so that the number of approval steps stayed below 6.
If you notice Workflow publish errors as you add more approval tasks you can follow the steps outlined in the blog post below:
- Audit Requirements: We had some important Audit Requirements on time stamps, version history as well as all change requests and comments added to the tasks completed. As you may already know, SharePoint cleans up workflow history for all Approved Items after 60 days, for performance reasons, correctly so. We had to develop a Timer Job that takes all data from Tasks List and Workflow History List for all approved items and migrates it into a destination list in a report format. We added lookup columns in both the source and destination lists to each other for a better user experience.
- Workflow History Page: Many of our users are on the Mac Platform, and so our requirements from the Beginning was to make this completely browser based. Using SPD, we modified all Task Approval Emails to contain a direct link to that particular Task Approval Page and Workflow History page. That way the users do not need to depend on the Complete Task button in Outlook or first have to go to the List, click on the link to the Workflow History page in order to approve tasks (as shown in the screenshot below):
Our customer wanted some major changes to the layout of the Workflow History page, such as hide the Terminate Workflow links, and hide any links that can allow users to delete tasks. Since the Workflow History page is just an aspx page in the layouts folder, we copied it with a different file name and modified the original one.
Shown below is the original OOTB Workflow History Page with several links our customer wanted removed:
Shown below is the modified Workflow History Page with those links removed:
- Tasks Approvals Page: It is possible to modify the look and feel of OOTB Tasks Approvals page, since it is a combination of an InfopathForm and an ASPX page in the layouts folder named WrkTaskIP.aspx (as shown in the screenshot below):
- Collect Data task: If you use a Collect Data from a User Action, remember it is not possible to Request a Change back to another user in the workflow on that action OOTB.
- Terminate/Reject a Workflow: Another challenge we faced is that, suppose a workflow has 5 approval steps, and, an approver rejects a workflow at step 4, or if a workflow is terminated at step 4, it is not possible to start the workflow again at step 4. It has to be started at step 1 again and repeat all the approvals from the beginning.
