JUser: :_load: Unable to load user with ID: 2547

Deploying SharePoint Workflows: How to Cut Workload and Minimize Risks

Posted in Business Solutions

SharePoint workflows are great at streamlining and tracking processes, ensuring their compliance, and automating tasks. Workflow automation is a must for all companies wishing to have their internal methods functioning smoothly and effectively. It makes sure that a process runs in the correct way, allows to track its current state, and speeds it up by delegating many tasks from people to computers. Things that used to be done in days now take hours. SharePoint workflows is a popular tool to help you achieve this goal. However, there are some limitations that can cause deployment challenges. Fortunately, prospective planning and good communication with business users offer a nearly 100% chance of success.

Tool for the Job

First of all, you need to choose how you would like to deploy a workflow in SharePoint environment (if a process really needs deploying one, which is not always the case). For starters, Microsoft offers some OOB workflows ready to launch without further work. They however cover only a couple of simple scenarios, not allowing for their modifications, so most likely they will not suit more complicated processes.

Workflows can also be created in Microsoft SharePoint Designer. It is a free tool, integrated with Visio and InfoPath and able to modify OOB workflows. SPD works well with automating common tasks, but its limitations – it cannot for example make satisfactory loops or import data outside the current list – make it hard to manage large flows.

The other pole of the spectrum is occupied by Microsoft Visual Studio. It can model practically any process, using data from entire SharePoint and LOB apps and going down to the slightest detail. This powerful tool nonetheless requires qualified staff to run it, development cycle can take some time, and its licensing costs may be out of reach for smaller companies.

Third party tools may fit the needs of most organizations. They are highly customizable, allow for graphical process definition and multiple activities, and can use data from other sites, site collections, or LOB applications. Their interfaces are often configurable so you can create one more adjusted and adapted to your needs. On the other hand they require fine tunings in enterprise deployments – if you deal with a large list you need to proceed carefully to avoid crashing the server. Sometimes you will also need to write your own piece of code to skip some obstacle. Licenses may as well cost a bit, and users may sometimes encounter unexpected limitations.

So, which tool is the perfect one? None. In an ideal world you would pick the most functional solution, putting license costs on a distant spot. In reality money matters most, regardless of functionality and offered support. Taking that caveat into account we may guess however that 3rd party tool would be the best choice in about 80% of cases. For a one-time license investment you get shorter deployment time than in SharePoint Designer and Visual Studio and much more possibilities than in SPD and OOB workflows. The remaining 20% are either very simple business procedures in the range of SPD and OOB workflows, or extremely efficient and highly customized workflows where Visual Studio works best.

Tackling the Challenges

When discussing number of challenges that may arise during workflow deployment we can divide them into four groups.

1.    Functionality and UX

SharePoint OOB interface may not be the easiest tool to work with. Will the process be understood by its user? Will he or she know to start a workflow? Is it too complicated? What does he or she really needs?

Limitations of a workflow tool you use may hinder the effectiveness of the process. What about such things as loops, lookups, automated activities? Can they be included and if not - how to replace them?

The level of process maturity also matters. Is the process defined well enough to implement? Does it fit organizational requirements? Perhaps it should be modified before deploying a workflow?


Not only the end user must understand the process – you should do so as well. You need to know exactly what is its business purpose. Don’t hesitate to contact a process analyst if needed. Try not to adjust the process to the tool – it should be the other way round.

Do not assume SharePoint UX is enough. Keep that in mind even while naming a workflow. Would you as a user prefer working with “Workflow 1” or, for instance, “Design a new book”? The same goes with decisions: make sure they are named and described in a user-friendly manner. Apply tasks or filtered views to make users see only their items of interest and not get overwhelmed by the whole workflow structure.

Be careful with forms: double check if advanced forms are required. If you decide not to use them and then change your mind during the deployment you will need to make some very difficult workarounds to set things straight. If you decide to create advanced forms, choose the right tool to design them (SPD/Infopath/3rd party/custom) and know their limitations.

2.    Permissions

You will face SharePoint permissions model and its limitations. Therefore you must know which data do you need. Who and how can access or edit it? Who has permissions to make decisions? Are permissions static or dynamic, given to a user or a group, attributed automatically or manually?


Get business requirements first. Then plan for security – make the workflow architecture as foolproof as possible. SharePoint has many limitations which in that case may actually help: per item permissions, column permissions, permissions to launch and terminate workflow, and finally permissions to accessing tasks and decision interface. Remember about admin accounts and substitutions – how substituting one user with another who has different permissions will alter the workflow? Active Directory and user groups will help you cope with the matter.

3.    Data structure

What data relations do you need and why? Will the dictionaries change or not, and if they will, how often? How and when retrieve data from external sources – do you look for synchronous or asynchronous model?


Try to define all the objects as soon as possible. It is important that you know SharePoint limitations regarding relationships, user interface, related fields, and performance. If you are dealing with external data, know the limits of external lists and be careful with their synchronization with SharePoint environment. For the sake of efficiency limit the number of queries.
Do you need standard or custom lookups? Custom ones work better with large number of items but require time and money.

4.    Performance

Workflow uses a lot of resources. The number of starting and concurrent workflows as well as number of items on the list may affect an overall performance. What to do to keep resource usage low?


Before you start to deploy a workflow ask how large it will be – how many items, users, and processes you can expect. Optimize the farm: take into consideration front-ends, database, timer location, pool recycling, and timer recycling. For recommended limits check Technet and MDSN.

Your work does not stop after a workflow is ready. Analyze its performance and remodel or rewrite if necessary. Look out for queries, loops and cascading workflows – they put the biggest strain on a farm. Keep in mind what is in the archive: the number of items and the workflow history.

Advice that never fails

Finally you may want to remember those general tips that will be useful in every situation. When in doubt, standard software development rules apply.

  • Do not assume that your work ends when a workflow is designed. Work with the business and help them understand what you have done. Find and take care of power users who can inform you about the process performance and can teach other users how to use it. Share the process with end users and stakeholders as often as possible.
  • Expect changes and prepare for them. Optimize the process after every change.
  • While designing always think about future performance.
  • Don’t forget about testing and deployment. Testing a workflow may be more complicated than testing a typical application as there are lots of paths to check. You should definitely test a workflow BEFORE running it on production environment. If a live workflow encounters some errors, results may be catastrophic.

Tomasz Głogosz is the project manager and main architect of Datapolis Workbox, a no-code workflow 3rd party tool for SharePoint.