SharePoint Designer Workflow Limitations

The limitations below are listed in relative priority with the most important or most likely to be encountered toward 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).
• 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, using a Visual Studio 2005 workflow, or sending the email from an event.
• You cannot group logical conditions within a step by using parenthesis.
• Workaround: Modify your expression such that the order takes precedence. For example, instead of “x=1 and (y=2 or z=3)” use “y=2 or z=3 and x=1”. .
• 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.

• 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.

SharePoint Designer 2010​ has a limitation when trying to implement a workflow action to send an email to multiple users based from lookup from a people picker control that accepts more than one user. By default the email action will only email to the first user and will not detect multiple users.