Common Challenges with SharePoint and SharePoint Designer Workflows

The SharePoint technology offers a wide spectrum of possibilities for implementing workflows, starting from the option to configure and use some of the workflows available out-of-the-box in the product and arriving to the possibility to code completely custom workflows in Windows Workflow Foundation using Visual Studio. This capability was already available in WSS 3.0/MOSS 2007; it has been enriched in the new versions of the product (SharePoint Foundation 2010 and SharePoint Server 2010) with some nice features and much better tools. Among the many posts that are and will be available on the internet on this subject, for an introductory reading I suggest looking at Overview of Human Workflow in SharePoint 2010 (by Sean Gabriel) in the official SharePoint Designer Team blog.

The SharePoint Designer [SPD] tool, which is completely free, allows a SharePoint web site administrator to better organize the presentation, the configuration and the behavior of its web. The SPD includes the “Workflow Designer” a tool enabling the design and the deployment of “declarative workflows”. A “declarative workflow” is a workflow that is completly described by an xml file (XOML); for this reason, such a kind of workflow is “code-free”: the xml file contains only the organization of the “activities” to be executed, accordingly to the logical (conceptual) workflow expected behavior. Obviously, such a zero-code workflow design is possible only thanks to the fact that many out-of-the-box “activities” are available in the “Workflow Designer” tool and in the SharePoint runtime environment.

The new version of the tool (SPD 2010) has a totally redesigned UI and a completely new “Workflow Editor”. The improvement that I love more concerns the easier representation of a workflow: in SPD 2007 a workflow could be realized strictly as a sequence of “steps”, each of them composed by a set of “activities” to be executed in a parallel or sequential mode (optionally in a “branch” chosen accordingly to a logical condition); in SPD 2010 the steps and the logical conditions can finally be nested at any level, allowing the organization of the workflow in a way much more adherent to its conceptual “flowchart” representation.

The is a lot more to say about the Workflow Editor in SPD 2010 (for example, the possibility to import/export the workflows as a Visio diagrams; the new keyboard shortcuts; the new built-in activities;…); for more information about the SPD and the new Workflow Editor, I strongly suggest to follow up what is periodically published on the “SharePoint Designer Team Blog”.

 

In my experience, designing and implementing workflows with SharePoint Designer (SPD) 2007 or 2010 is an easy but not trivial task, especially when the workflows to be implemented have not a trivial behavior and/or when creating and deploying custom activities is not an option (because you do not have the skills or because the target SharePoint environment does not allow the deployment of custom assemblies and artifacts).

Here below I list some of the common challenges that need to be considered. Some of them have already well known solutions; others are less documented on the Internet.

· A workflow is often conceptually designed as a flowchart; a flowchart can have “loops”. How to create loops in a declarative workflow designed in SPD?

· Some workflows can be easly designed as a “state machines”. How to implement a state machine workflow in SPD?

· In SharePoint, only one instance of a given workflow type can be running at a given time on a given item. In many situations, this behavior is welcome because it allows the “safety completion” of the running workflow instance. For example, supposing that the startup of a first workflow instance on a certain list item was triggered by the list item creation and that this instance is now waiting for a certain task completion, an update on the same list item will not trigger the startup of a new workflow instance; this is good: a second instance could potentially duplicate the logical workflow execution! Unfortunately, when you make even a very little change on a workflow implementation using SPD, a new workflow type is created (I say “unfortunately” in this context, but this is also a great and welcome workflow versioning mechanism…!). If there is already a running instance of the previous workflow type on a given item (maybe waiting for a certain task completion…), it can happen that a new instance of the new type starts too (for example, triggered by a simple update on the same item even caused by the first instance after the task completion!); this duplication of the running workflows on a given item can be the cause of… a lot of confusion! Just think about the problem of the duplicate tasks! How to minimize the consequences of the workflow instances duplication caused by the versioning mechanism? [20100406 UPDATE: I added details about this subject on this post: Declarative workflow versioning and workflow instances duplication ] .

· When you design a workflow with SPD, you often think that your users kindly add and/or update the list items one after the other, using the standard forms. Unfortunately, many of them have a lot of data entry to do; that’s why they use and love the “datasheet” views and the cut & past action from the Excel spreadsheets…! (Here again, I use the word “unfortunately” because I am thinking about the consequences for the workflows; you know, datasheet views are just great...!). Suppose that you have a workflow starting on an list item creation and suppose that this workflow is designed to update suddenly a certain field on the same item (for example, a “status” field; quite a common situation…) before pausing for a new task completion; what happens if your users create and update bunch of items in a data sheet view, possibly on a busy server? We have noticed that some instances will fail with a not clear error message stating that “an error occurred while updating a list item”. How to minimize the risk of this startup failures?

· The SharePoint security model does not allow for setting permissions on the single columns of a specific list. It may happen that some columns contain data that should not be directly updated by the users, because you want that this information will be “managed” by your workflow. For example, a column could contain the current “status” of an item and a running workflow instance could be waiting for a human task completion, at the end of which the workflow instance should be able to read and update the content of status column accordingly to the current status; what happens if, during this waiting time, some user changes the current content of the “status” column? Of course, the workflow is cheated and will behave consequently… So, how to minimize the risk that the users updates especially “sensitive” columns? [20100407 UPDATE: I added details about this subject on this post: Rapid “Data Collection” Solutions – Part 4: designing and implementing a security model ] .

· The SharePoint workflows functionality offers a built-in mechanism for logging the history of a workflow and for showing it in a standard “Workflow Status” page; is this mechanism always enough or is it sometime preferable to create a custom history list with a custom “Workflow Status” page? [20100312 UPDATE: I added details about this subject on this post: Rapid "Data Collection" Solutions - Part 3: designing and implementing the business process ] .

· The SharePoint workflows functionality offers a built-in mechanism for involving the human intervention on a given workflow instance; this is based on “Tasks” list: a list item (task) is created and assigned for each required user intervention; after the creation of such a task, the workflow instance automatically pauses; when the task is marked as “complete”, the workflow instance resumes and continues its execution. The workflow designer in SPD is able to automatically create the forms required to represent each specific type of tasks: these forms (which can also be easily customized with the same SPD) automatically contain the controls for the fields that must be filled-in by the involved users. When a specific task is complete, by default it remains on the “Tasks” list and will be listed as complete on the “Workflow Status” page; often the completed tasks contain valuable information (for example, the comments about the approval or the new “status” for the item, as chosen by the involved user). Is this mechanism always the best or is it sometime preferable to copy back the data from the completed task to the current item and to delete the completed tasks? [20100312 UPDATE: I added details about this subject on this post: Rapid "Data Collection" Solutions - Part 3: designing and implementing the business process ] .

· The just mentioned “Tasks” list has a nice feature allowing to automatically sending an email when a task is assigned. Unfortunately this mechanism send an email for each update on a given task; for example, a simple task created and completed causes the arrival of three emails on the assignee inbox: the first one is very welcome, stating that there is a new task to be completed; the second one informs the assignee that the task was modified (because of the completion) and the third one informs the assignee that the task was completed (often by himself…). This simple behavior is logically correct: if the assignee of a given task is a SharePoint group, it is very important that every member of the group knows about what is happening on the task. Unfortunately, when the assignees receive a dozens of tasks every day, they do not like to have all these details on their inbox; in this situation, a custom mailing mechanism is required, sending the emails with a more controlled logic. But there is a problem: each notification email should contain a link to the notified task; when the task is created (and, so, the link is available), the workflow pauses until completion (and, so, will not send the email until the task is completed!). So, how to organize a custom mailing mechanism?

· Many times a running workflow instance requires knowing the current date and time (for example for comparison with other date and times and/or for writing that information in some list item field); it is trivial to get the current date, but how to get the current time?

· Sometimes it is necessary to create a “time controller" workflow, that is a workflow that will periodically check the “status” of a given list item in order to compare it with the expected status on that specific timeframe. So, how to create a time controller workflow?

· It may happen that your workflow dynamically assigns tasks to people or groups; it may also happen that new groups are created and/or new users added to the current web after the initial workflow deployment. On a WSS 3.0/MOSS 2007 environment, even if these new users and/or groups are correctly authorized on the web’s lists (here included the “Tasks” list), it may happen that they receive an access denied error when they try to access the workflow’s custom tasks forms (which are ASPX pages for SPD 2007 designed workflows). Why this happens? How to authorize the new users and groups on the custom workflows tasks forms? [20100317 UPDATE: I added details about this subject on this post: Dynamic tasks assignment and access denied errors in declarative workflows [SPD 2007 only] ] .

· The “Tasks” list has a predefined view allowing the users to see only the tasks assigned to them. Unfortunately, often the tasks are not assigned to individuals but to groups, and often these groups are defined directly in SharePoint. There is no way to create a view showing the tasks assigned “to me or to the groups I belong to”. So, how to help the users finding the tasks assigned “directly or indirectly” to them?

· The tasks created by a workflow in the “Tasks” list are not automatically secured, in the sense that there is not a permission assignment allowing only the assignee to modify them. How can the tasks be secured? [20100407 UPDATE: I added details about this subject on this post: Rapid “Data Collection” Solutions – Part 4: designing and implementing a security model ] .

· [20100323 - A new important advice, just found in " Using SharePoint workflows with Business Connectivity Services (BCS)", a great post by JD Klaka on the BCS Team Blog] Reading multiple values from the same external list item does not cache the item. Because of this, the activity will first call the Read List method (Finder) and then the read item method (Specific finder) for each column read. So if you are reading 10 properties in a list of 2000 items, this will cause 20 calls to the BDC and 20010 items being pulled from the backend. How to reduce the workload caused by the workflow on the external system? It is possible to find a solution with detailed explainations in the following posts: "Using SharePoint workflows with Business Connectivity Services (BCS) – Sandboxed Workflow Actions" and "Using SharePoint workflows with BCS – Full Trust Workflow Activities" by the same author.

· [20100323 - Another precious advice by JD Klaka, taken from " Using SharePoint workflows with Business Connectivity Services (BCS) – Sandboxed Workflow Actions "] Sandboxed actions can cause your workflow to fail if it fails to obtain a sandbox worker process application domain. There are an administrator configured fixed number of these application domains, and they are shared with all sandboxed code (actions, web parts, event receivers, etc.). Because of this, be cautious of using sandboxed actions in the following situations:

o Complex sandboxed code actions that take time to complete

o Slow external lists

o Environment where many workflows will run at roughly the same time

o Scenarios that cannot handle workflow failures

 

When implementing workflows with SPD, it is often necessary to consider these and other challenges. I am planning to write my experiences about solutions and workarounds in my next posts...