locked
Task list workflow does not kick off RRS feed

  • Question

  • Have 3 SPD related workflows - Workflow A, Workflow B, and a Task List workflow.  Workflow A kicks off when a form is submitted.  Based on specific item column values, Workflow A may invoke Workflow B (Start Another Workflow) and then terminate.  Both Workflow A and Workflow B have tasks that use the same Task List.  A separate task list workflow sends the 'assigned to' email with the link to the task page.  This works just fine for tasks generated in Workflow A.  But the task list workflow does not kick off for Workflow B tasks, even though the tasks are in the correct (same as for Workflow A) task list.  I have tried the following, none of which have made a difference:
      1.  Updated system account permissions to 'full control'
      2.  Turned 'send email notification' in Advanced List settings for the task list back on - thought maybe Sharepoint would automatically send email out, but didn't happen

    Since the Workflow B tasks can be edited via the task list, I am totally stumped why the task list workflow would not kick off.  Does Sharepoint not recognize tasks of a workflow begun via another workflow as newly created tasks?

    Any ideas would be appreciated.

    Thanks,
    Shelly

    Tuesday, October 6, 2009 4:17 PM

Answers

  • If I understand your scenario correctly, Workflow A is a regular SPD workflow that starts when an item is created.

    But Workflow B is triggered only by Workflow A using a custom action "Start workflow".

    This means Workflow A is running as the user who created the form. But Workflow B is running as the system account because it was triggered by a custom action. So according to the security fix described above, Workflow A can trigger other SPD workflows, but Workflow B cannot (because it is running as system account).
    Tuesday, October 6, 2009 10:11 PM

All replies

  • Does the workflow kick off properly but the task is just not generated?


    If so then it could just be an error in the logic.  Ie: Run this task only if user = "bob" and bob is not the user so therefore the task never kicks off


    Kevin
    Tuesday, October 6, 2009 4:42 PM
  • No, the task IS generated - it is in the task list.  The associated workflow doesn't kick off even tho it is a newly created item and the task list workflow is set to begin on create.  The odd thing is that it kicks off just fine for tasks generated by Workflow A - just not for Workflow B, even tho all the tasks from both A and B workflows are in the same task list. 
    Tuesday, October 6, 2009 6:06 PM
  • Seems like a permissions issue described in this SPD bog post, where declarative workflows can no longer be triggered by the SharePoint System account.

    "Declarative workflows and user context"

    http://blogs.msdn.com/sharepointdesigner/archive/2008/09/28/declarative-workflows-and-user-context.aspx 


    "Start another workflow" is not an out-of-box workflow action. Seems like that custom action is elevating permissions to System Account and trying to start Workflow B, the SP1 fix described above does not allow this.
    Tuesday, October 6, 2009 7:41 PM
  • I must be missing something, but I don't see why permissions would be OK for a Workflow A task but not for a Workflow B task.  All the tasks go to the same task list, so either a workflow should kick off or not.  I gave system account full control permission, but it made no difference.  Issue must somehow be related to starting a secondary workflow, but don't know why the tasks in that workflow, once created in the task list, wouldn't cause the task list workflow to begin.
    Tuesday, October 6, 2009 9:50 PM
  • If I understand your scenario correctly, Workflow A is a regular SPD workflow that starts when an item is created.

    But Workflow B is triggered only by Workflow A using a custom action "Start workflow".

    This means Workflow A is running as the user who created the form. But Workflow B is running as the system account because it was triggered by a custom action. So according to the security fix described above, Workflow A can trigger other SPD workflows, but Workflow B cannot (because it is running as system account).
    Tuesday, October 6, 2009 10:11 PM