SharePoint Designer workflows are have some great benefits: they are relatively easy to create, don't require any code, and can be created and maintained by power users, not just developers. However, there are several limitations to SharePoint Designer workflows and you can hit these edges relatively quickly. Before deciding to go down the SharePoint Designer workflow path, you might want to understand these edges as you may have to do more work to create the solution. Nearly all of these limitations listed further below can be solved through one or more of the following techniques:
- Create a Visual Studio 2005 workflow instead and connect it to the SharePoint list.
- Create a SharePoint list event and handle all of the needs within the event.
- Create a SharePoint list event and initiate a worklfow from the event. See Starting Workflows from SharePoint Events.
- Create custom SharePoint Designer Actions or Conditions.
Limitations The limitations below are listed in relative priority with the most important or most likely to be encountered towards the top.
- You cannot access the previous value of a field. This means that you cannot check to see if a field changed. There is an action that waits for a field to change, but you must provide the value that it changes to. Alternatively you can compare it to another field, but not the previous value of that field. If the field didn't change at all but met the condition implied by the action, this wait action likely wouldn't wait at all and move on the next step in the workflow.
- Workaround: Use a SharePoint list event to track "ItemUpdating" and pass in the "After" value for a field (the current value will be the old value in a synchronous updating event). If you decide to also start this workflow from any asynchronous event (e.g., "ItemAdded" and/or "ItemUpdated"), you will need to pass in the event trigger (e.g., "Add", "Updating", "Updated") so the workflow can differentiate between them (the current item in the workflow will be the old item for synchronous events, but it will be the new value for asynchronous events). For an example of this, see: Starting Workflows from SharePoint Events.
- You cannot loop. If you want to perform an action on say all items in a list or all child items for a parent, you simply cannot do it unless you know how to lookup each item in the list at design time and have an action for each of those items.
- Workaround: Use Events or a Visual Studio 2005 workflow.
- You cannot lookup an item using two keys. If one key does not uniquely identify an item, you are stuck. You can try to just use one field, but the workflow will act on the first item it finds. You cannot use two fields to identify it.
- Workaround: Use Events or a Visual Studio 2005 workflow.
- You cannot copy the contents of one email action to use it within the same or another email action. This is true if there are any lookups within the email contents.
- Workaround: Copy by hand (re-write the contents) or after saving the .xoml file, open it with an XML editor (right click the .xoml file and choose Open With -> SharePoint Designer (Open as XML)), then copy/paste the appropriate data.
- You cannot put lookup information in the subject of an email.
- Workaround: The easiest workaround is to put the lookup information in the email body. More complex solutions involve creating a custom SharePoint Designer workflow action, use a Visual Studio 2005 workflow, or sending the email from an event.
- You cannot group logical conditions within a step by using parenthesis.
- You cannot easily log a value with context information to the workflow history list.
- Workaround: Use the Build Dynamic String action to store your log into a workflow variable then use the Log to History List action to log the workflow variable to the history list.
- You can run actions in parallel, but you cannot run steps in parallel.
- Workaround: Use a Visual Studio 2005 workflow.
Tips
Other than the workaround tips mentioned above, there are some things buried in SharePoint Designer workflows that are possible, but not obvious.
- You can relate to lists once or more removed from the current list. For example, you can use the current item and lookup to a related list and use that item to lookup to another list (or maybe a different item in the original list).
- You can build dynamic strings or calculated values and put them into workflow variables then use those variables to set list items. Note that the calculations are simple: plus, minus, multiply by, divide by, mod.