Hi Benjamin,
Have you thought about creating the workflow on the task list itself? You can trigger the workflow based on conditions and type of task. The Complete task button should change the percentage completion to 100% and status to Completed, as long as this is not there, you can run other actions with workflow on this task. hope it helps.
Let me throw something at this and see what you think.
First, I strongly suggest that a workflow should not be associated to a Workflow Task list to start a workflow on a created workflow task item. You are guaranteed to have locking issues on the tasks and users will not be able to complete tasks via workflow or UI.
But you can utilize a custom task list. Create a new list using the task content type. Not the content type of Workflow Task.
Your first workflow will create list items in the new task list using the Create Item action. You can then send them a notification that the task is created, send a link, and do anything else you need at this point. End the first workflow.
So now your users have a task that they need to work on. You can put incomplete tasks in a webpart on a home page, you can even easily filter it to show just the logged on users tasks. You can send reminder emails using a scheduled site workflow for incomplete tasks. Users can update the task status to "Doing", then "Complete" as they see fit.
At this point you can create a workflow on this custom task list that can either Start on Item Modified with the condition of the status equal to Complete, or start on item created and wait for Status equal to Complete. When a condition is true, continue processing as you need. If you need to start processing on the original item not found in the task list then you can start a workflow on that item easily. (when the task item was created you also can save the originating list item ID as metadata to the task item). Use the web service call to StartWorkflowOnListItem, see more at Start a Workflow using a Web Service
The started workflow can then complete any final processing needed.
I know this seems complicated, and added workflows seem over engineered, but I see separations of concerns as a bonus. It is also easier to update a specific part of the process in its individual workflow.
Hi Andrew, that is a very different direction to what I was trying, I am trying to figure our how I can implement your idea into the below situation
I currently have one large form an initiator submits when they have a new staff member. They select various induction items (tasks) that are required to be completed by other staff within the business.
Based on the selection I wanted tasks to be assigned to the various business functions (HR, IT etc) to be completed by those business areas. I assign these tasks with the Request Data action, say HR has a potential 10 items available for the initiator to select and they select 5. I use the form formatting functions to only display the selected 5 tasks on 1 Request Data action form.
Each business area can have several staff to complete the tasks assigned to that business area over a period of time, hence why I created the Required Data action to allow for updating by multiple staff rather then just the completion of its action.
I am using the parallel processing action to allow each business area to update and complete their assigned induction tasks at the same time. Once completed I was going to have the system collate everything together and report back to the Initiator.
There is one important issue though, one of the IT tasks (User Account) is needed for other business area's to start their tasks. So I wanted to trigger their Request Data actions when IT has completed the User Account task. IT could potentially have 10 or 15 different tasks, so it may take a while for their Request Data action to be fully complete and allow that tree in the workflow to continue. I would prefer not to have two Request Data actions for IT.
Additionally some important key tasks, upon completion would send a notification to the initiator.
Its those last couple items I am struggling with, as I can't seem to access the content of the data within an ongoing request data action, or have the request data action submit the partially completed action content to the SharePoint library so I can trigger another workflow.
Ok I think I have figured out how to design this based around your suggestion.
I can keep that initial induction form, when an initiator submits it, I can have a workflow run on items that were selected as "Requested" which will add them as tasks on a second custom list with the task content type. I can have the the tasks identified by the request title and split down by the business area they are under, then assigned to a specially made sharepoint groups for each business area (to allow differing staff to action the same tasks)
I can then trigger a workflow to run when the User Account tasks is updated, or have workflows run on any important actions if needed.
I am not sure how I would identify how all tasks per that initial request are completed, other then having a workflow that constantly checks if the each tasks under the same request title = complete.
My concern with this solution is that it takes the users who are completing these tasks, out of clicking on 1 link in an email that will display 1 form with all the tasks for their business area per request on it. Into looking at each individual task for every request (grouped and sorted nicely) within a SharePoint list.
Anyone have any recommendations on which method sounds the most user friendly?
The email notification to users that there are tasks to complete can be one email per role. The email could include a link to the task list, but to a specific view. You could create a view per role that would filter to only show tasks of that role. Then in the view also filter out completed tasks and group by process. This grouping can be done by including a unique ID to all created tasks that equals the list item ID from the original workflow/item.