4

I have a list WF called Submissions that is associated with List A. The desired scenario is described below:

  • Users go to List A to enter information and Submit
  • Once submitted, the WF in List A kicks off
  • List A's WF has logic that will add the newly submitted information from List A to List B
  • Information entered in List A is then added to List B as a newly created item
  • List B has a WF called Review that starts a Task Process for Administrators and notifies them

On both of the WFs I have the Start Option as "Start workflow automatically when an item is created".

When a user enters information in List A the WF kicks off no problem. But when the information from List A is added to List B, due to the WF logic in List A, the WF in List B does not kick off at all to start a Task Process for Admins.

The logic is sound but I don't have any idea why the WF in List B is not kicking off when a new item is added from List A.

Can someone enlighten me on how this is not working and advise on a fix?

  • are you using any impersonation steps? I have had weird things like that going on in the past when using impersonation. Is this happening to System account or another account. Also, is the same thing happening for on change? – ova Mar 16 '16 at 16:21
  • @ova I'm not familiar with impersonation step and not using it at moment. can you point me or show how to do so? Also, I'm not using System account only my normal one. However, my account has Farm Admin rights. Not sure if that counts for anything. As for on change what do you mean by that? Please advise. – Aspire27 Mar 16 '16 at 16:32
2

This is because the system account, by design, can't start a workflow. You need to do the create new item in list B inside an impersonation step. I use a service account named sp_workflow to publish the workflow so that it doesn't look like I created all of the items in list B.

  • Hi Erin. I have not performed an impersonation step before and would need advice on how to. When you say "create new item in list B" are you saying I should remove the "create new item" logic in List A? As for publishing WF as a service account, are you saying that I should create another account to publish? Please advise. – Aspire27 Mar 16 '16 at 16:36
  • Inside a step in your workflow on list A, create an Impersonation step (there's a button in the ribbon). Inside that step, put your "create new item" step. You can publish it as yourself if you wish. But the documents I have are somewhat sensitive, so I don't want my name in the Created By column. To avoid this, I had my admin create a "service account" in central admin, then publish the workflow logged in as the service account. – Erin L Mar 16 '16 at 16:40
  • I see. It seems as if I'll have to build this as a 2010 WF platform because 2013 deprecated this. So the only thing I have to do, just to clarify, is to use impersonation step in List A for "creating new item" and that's all I have to do? I'm sorry for these questions as I've never done impersonation before. And thanks for your time Erin. – Aspire27 Mar 16 '16 at 16:49
  • It looks like you can use App Step in 2013 if it's enabled in site features: qdoscc.com/blog/… – Erin L Mar 16 '16 at 16:52
  • I have successfully used the App Step in List A to create a new item in List B it works. However, the WF in List B that should kick off on new item creation is not doing anything. I created the App step in List A however on your initial response you said to do it in List B. I'm confused. Any idea on what I'm doing wrong here? – Aspire27 Mar 16 '16 at 17:26
0

You are correct and this is a known issue and was included as functionality within an update in SharePoint 2013 to prevent an infinite looping workflow. There is a workaround procedure to manually call the 2nd workflow from within the 1st workflow.

Just a heads up on a 'gotcha' regarding the workaround. If you are creating/assigning a Task item to kick off workflow B, by default the workflow will pause until the Task has been marked as Completed (Approved/Rejected). This is a problem because then the code to manually start workflow B will not run until after the Task is completed. There is a setting in the task itself you can uncheck so the workflow does not pause until the task is completed, and that will resolve the issue.

enter image description here

0

Two approaches I use for this kind of requirements;

  1. You can use 2010 workflows if all the functionality you need is included.

  2. Alternatively most of these kind of requests can be reduced to single workflow. In your example, it is most likely to be possible to have the workflow in List A to do whatever needs to be done for the item in List B. Once you create the object in List B, it returns a Created variable which references the new Items ID. This allows you to access its columns for read/write purposes.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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