SharePoint 2013 Workflow, Creating an Item with REST, and Declarative Workflows

Question

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]

Notes

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?

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