Last week, I asked a question about looping over a managed metadata field in order to build the necessary web service endpoint so that I could create a list item somewhere else based on seelctions in that MM field.

Thanks to a user on stackexchange, I was able to resolve that issue and created the following workflow:

Set Variable: [TempVar] to [%Current Item:MMetadata_0%];

    **Loop while [TempVar] contains ;**  
    Find ; in [TempVar, output to [DelimitIndex]  
    Copy from [TempVar], starting at 0 for [DelimitIndex] characters, output to [CurrentVal] (1)
    Trim [CurrentVal], output to [CurrentVal]
    Set [postURL] to https://sitecollection/site/[CurrentVal]/_api/web/lists/getbytitle('DocSetBuilder')/items (2)
    Build [contextHeaders] Dictionary (3)
    Call https://sitecollection/site/[CurrentVal]/_api/contextinfo (response to [contextResponse])
    Get d/GetContextWebInformation/FormDigest from [contextResponse], output to [digestValue]
    (For brevity's sake, I'll omit the four dictionaries I have to build to make the POST call, unless someone wants to see that)
    Call [postURL] with [postPayload] (response to [responseResult])
    Calculate [DelimitIndex] plus 1, output to [nextDelimitIndex]
    Copy from [TempVar], starting at [nextDelimitIndex], output to [TempVar]


  1. Managed metadata terms come with their name, a bar character and a guid (i.e., Term|1234-423423-afdsjf). I have to do the exact same Find delimiter, copy from 0 to delimiter, output to Current val in order to get rid of that stuff.
  2. Bizarrely, there's no path to create document sets from the 2013 REST API (I've made a post to uservoice about this glaring oversight; please vote for it). Apparently you can do it in CSOM with the 2010, but not in workflow. So my solution was to have a custom list that carried the two pieces of metadata I needed to create my subsite document sets and then have a standard 2010 workflow (called DocSetBuilder) kickoff on item creation in that list to create the desired document set. More on that in a second.
  3. In spite of varying sources to the contrary, you must make a post to /_api/contextinfo in order to get the X-RequestDigest, otherwise you get a 401 from the web service.

So, the loop works just fine, creates a list item in the appropriate list on the appropriate subsite based on those selections. Unfortunately, that new line will not kick off my workflow. It's created by the System Account.

Things I've Tried:

  • Using the process described here to ensure declarative workflows can be started by the System Account (appears to only apply to items created via email?)
  • Enabled the Workflows can use app permissions feature everywhere.
  • Used the process described here to give the workflow service full control.
  • Put the web service call that creates the subsite item in an App Step in SPD.
  • Attempted to kick off DocSetBuilder on edit using a 2013 workflow (SetStarter) that edits the item, both in and out of an App Step.
  • Attempted to kick off DocSetBuilder directly by using the Start a 2010 Workflow action in SetStarter. Both in and out of an App Step.

This has also been posted at /r/sharepoint, just in case.

Anyone here have any insight?

  • Are you trying to have a workflow start another workflow?
    – MickB
    Commented Mar 17, 2016 at 18:38
  • Well, technically, I'm trying to have a workflow (which is configured to start on item creation) start when a new item is added to a list via a web service call performed by a workflow. I think I've got the solution, but I won't post it until I've tested it for sure. Commented Mar 17, 2016 at 19:01

1 Answer 1


The workflow recursion prevention measure was put in place to mitigate the following scenario:

1) We have two workflows and both activate on item updates in the same list.

2) The workflow also updates list item in the list causing an infinite loop of workflow activations.

Basically you cannot rely on the start options on your workflow when you create/update a list item. You will have to explicitly call the workflow yourself through REST.

Here is a blog post on MSDN that walks through an example on doing so:

FIX: SharePoint 2013 Workflow recursion prevention – Part 1
FIX: SharePoint 2013 Workflow recursion prevention – Part 2
FIX: SharePoint 2013 Workflow recursion prevention – Part 3

  • That post is exactly what I was working from when I mentioned that I thought I had a solution. I'll go ahead and mark this as the answer. Commented Mar 17, 2016 at 19:39
  • Hmm, I'm thinking that might have been a touch too soon. I'm getting an OK from the web service call SP.WorkflowServices.WorkflowInstanceService.Current/StartWorkflowOnListItemBySubscriptionId, but nothing at all is happening at the other list. I try to run that endpoint in a Fiddler-like thing I've got, and I get a 404-error. Commented Mar 17, 2016 at 20:04
  • I can confirm it works, it took me a bit to get it as well. We had a request to keep a bunch of lists in sync between parent/children and I used this method to do so.
    – MickB
    Commented Mar 17, 2016 at 20:22
  • I think it might be a patch issue. Researching... Commented Mar 17, 2016 at 20:25
  • 1
    Apparently that final web service call, StartWorkflowOnListItemBySubscriptionId doesn't exist before the May 2014 CU. We're on SP1 for some incredibly stupid reason. Commented Mar 17, 2016 at 20:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.