1 of 1 people found this helpful
I think the recommended way would actually be the way you've done it there, using a separate pre-condition after each status. This would be the simplest fool-proof way of ensuring the call cannot be closed with open Tasks on it.
Thanks Hadyn. I'll really like to try and get the process back to a status of In Progress though - at the min we haven't pushed out Self Service to End Users but we will be and as it stands at the minute it'll look to them as though everything has been done even though it hasn't. Of course I could be making a mountain out of a molehill as this situation doesn't happen very often but I'd like to have all bases covered - I'm getting too bloody pernickety in my old age
I think that perhaps not allowing a task to be re-opened might be one good solution to be honest. If a task was completed then someone must've done the job (you would hope) so if it is being re-opened then I assume it is for something which was unforseen and then perhaps should be recorded as a seperate task that they had to undertake? Or as Haydn says, only allowing the action to return the status back to In Progress by hiding the Close action is a good route.
If not though, the only solution (not tested - just a vague idea) I can think of would be a scheduled bulk action based on a calculation that sets a boolean to True. A calculation on the process calculates that if the number of task collection records not at an end state returns a value over 0 and the status = All Current Tasks Complete then a boolean is set to True, then a scheduled bulk action based on a query looking for that boolean, could run a manual action that moves the status back to In Progress for you. I must admit that I haven't done that much with calculations yet so you would need to check that this is possible.
I wrote up a similar-ish type scenario a little while ago which would hopefully be helpful if you decided to go down that (quite complicated) route:
Thanks Karen - as you say tasks shouldn't be completed if everything hasn't been done on them however we do have the odd instance where it isn't done right so in order to report on the SLA properly the task should be reopened. If we create a new task then that's starting a new SLA clock. Although I'm beginning to see why in the old process the action reopen wasn't available!! I'll have a go at what you suggested (thank god for pre production cause I'm definitely going to break it!!). Or if LANDesk feel like changing the process design functionality to allow a decision after a status everything would be hunky dory lol
Just in case anyone else was looking to do this thought I'd post how I got it working. Spent another day on Friday trying to work with calculations and scheduled actions but couldn't get it sorted - came in this morning and had a brainwave of a really easy fix.
In my task object created a new boolean attribute Task Restarted and added this to my task window. In my task process added an auto action after the Restart to tick the boolean, then added a decision after the Complete to remove the flag - basically if a task is restarted it ticks the boolean and then if it's re-completed it removes the tick. In my main request process added another precondition after my All Current Tasks Complete status to check if the Task Restarted boolean is ticked. Created a dummy auto action after this that does nothing but lets me loop the process back to the In Progress status.
Amazing what a couple of days away from LANDesk does to refresh the old grey matter. Not a very high tech solution I will agree but end result is the process being at the status is should be.