Microsoft & .NETSharePoint 2013 Workflow Limitations and Work Arounds

SharePoint 2013 Workflow Limitations and Work Arounds content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

Introduction to SharePoint Workflow Limitations

In this article, we will be discussing the limitations with SharePoint 2013 workflows that was working in SharePoint 2010. We will also see some of the practices we need to keep in mind when designing the workflows. One of the examples is the nested Workflows that was supported in SharePoint 2010 is not supported in 2013. We will understand the limitations with the help of a business scenario.


The scenario is that there is a main list named “Project” that holds the details about the project, such as the “Project Name” and “Client Name.” A workflow runs on the ‘Project’ list that goes through the different stages of the project. On the UI, we need to display the tasks assigned to users with the project details it’s associated with. By default, the project information is not carried over to the task. The information that is available is the “Related Items” field, which links the task item with the original list item.

So, our approach might be to create a SharePoint 2013 workflow that runs once a task is created that will fetch the related information from the parent list. However, here comes the limitation where SharePoint 2013 doesn’t trigger a WF when an item is created from another workflow; in other words, if the workflow on the projects list creates a task in a task list and the expectation is to run a workflow on item created on task list, the workflow will not run. This was supported in SharePoint 2010 workflows, so the workaround is to create the workflow on the task list as a SharePoint 2010 workflow instead of as a 2013 workflow.

So, we create a workflow in SP2010 engine that will decipher the “Related Items” field and update the task list. The step by step process is to first create a list named “Project” and add three columns of type ‘Single line of text’ named “Project Name” and “Client Name.”

Similarly, create a task list named “Project Tasks” and add the columns “Project Name” and “Client Name” of type ‘Single line of text’. In the task list, we create two additional fields, a field named “RelatedItemString” of type ‘Single line of text’ and one a calculated field named “CalculatedItemId.” The formula for the “CalculatedItemId” is:


The ‘Related Items’ is an object that has the information of the ItemId, listId, and the WebId. The JSON format for the data looks like what’s shown in Figure 1. The JSON value is stored in RelatedItemString and it’s in the following format:

Figure 1: Storing the JSON value

The final value stored in CalculatedItemId is the “ItemId” value from the JSON.

Once the schema is created, the next step is to create the workflows. For this example, the workflow on the project list is a one-step SharePoint 2013 approval workflow.

The workflow on the “Project Tasks” lists that runs when an item is created will be a SharePoint 2010 workflow. The SharePoint 2010 workflow in the SharePoint designer is defined as shown in Figure 2:

Figure 2: The SharePoint 2010 workflow

One thing to note here is at times population of the “Related Items” is not immediate. On SharePoint online, it’s seen that it can get delayed up to 30 minutes. So, Point 1 in Figure 2 illustrates adding a wait handle for the related item to get populated before continuing with the extraction of the information.

In Point 4, the related Items JSON value is saved in a workflow variable and then it’s updated to the “RelatedItemString” column. The “RelatedItemString” is then used in the calculated field to extract the ItemId information.

Also note that the “CalculatedItemId” field is not populated immediately, so a wait handle is required on the “CalculatedItemId” field. Once the ItemId is retrieved, this can be used to retrieve the data from the Project list for that item. This is illustrated in Point 6.

Once ItemId is extracted, it’s stored in a workflow variable as shown in Figure 2, Point 8. The next step is to fill the information from the parent list to the task list. In Point 9, add a new action named “Set Field in Current Item,” click the ‘Fx’ button, and select the properties as shown.

Similarly, we can set any number of fields from the parent list to the task list. These fields then can be used to display a more informative UI.


In this example, we saw that triggering nested workflow is not supported in SharePoint 2013. It’s not just on the task list; any item created in any list cannot auto start the workflow on an item-created event. Related items is the key between the parent item and the task item; however, sometimes its population can be delayed. Because some string operations are not supported on designer workflows, we may have to introduce calculated fields to support the requirement implementation. In this , we also discussed the workaround is to use 2010 WFs for implementing nested workflows and also some scenarios to keep in mind while developing the workflow.

Get the Free Newsletter!

Subscribe to Developer Insider for top news, trends & analysis

Latest Posts

Related Stories