There are techniques using process design, mainly around statuses and pre-conditions that will carry out this type of functionality, however, you need to be very careful when using them as it does need a real understanding of what this does to both the main process and the task and what the knock on effects are likely to be.
Just based on what you're saying, I would add a new status on the main incident process that represented the creation and assigning of the task. You would need a manual action to take you there, but between that and the status would be an automatic Stop Clock action. Now, this is where you need to be sure of your process logic. You will also need to add an additional status in your Task process representing the delivery confirmation. You then create a Pre-Condition after the main Incident status that tests for any task being at the Delivery Confirmation status and follow that by an automatic Start Clock.
The resultant affect is that when the main process creates and assign the task the clock stops. When the analyst tells the task that it has reached the Delivery Confirmation status the process engine will automatically kick the main process which will find that the pre-condition is met and start the clock and move to the next status, whatever that may be.
I hope that makes some kind of sense? I'm not near anything that can help me draw it for you I'm afraid.
Thanks for the speedy reply. I was hoping for a mechanism that would do it without having to edit the main process as the Service Request process currently shares the Incident process (Until we go to 7.4). As it is, your solution is very neat and I can always copy the existing process and allow them to diverge slightly. Thanks for your help. I'll try it later on the development server.
No problem Tony. Let me know how you get on?
I know you have probably implemented this already but this would be of interest to anyone searching for this type of solution.
You must also be careful that your process doesn't allow a manual action of Stop Clock or Start Clock because, if the clock has been stopped manually when your automatic action to stop the clock occurs, then you will get an error.
To stop this you would need to put a condition before both the automatic actions of Start Clock and Stop Clock. I created a condition called Is Clock Stopped. If this returned true then you do not want the automatic Stop Clock to fire. You may then also need to put the condition before the automatic Start Clock action (i.e only Start Clock if Is Clock Stopped returned true). Of course you will not need the condition before the automatic Start Clock if you do not allow a manual Start Clock action for this status as you know the clock was definitely stopped previously.
Hopefully the attached shows it clearly.
IsClockStopped.gif 5.1 K
I have already implemented this. I decided that rather than use the process to do it, that I would instead use a bulk action as it gave me greater fine control over the number conditions that I could implement for the change of clock status. I could have used a condition but the precept of "the simplest solution being the correct one" seemed to apply so I did it this way. The potential loss of an hour (the schedule is set to run every hour) was perfectly acceptable to the business and therefore was the best way to go about this. The condition you are talking about is one that causes me some consternation as I see no reason why the automatic action cannot include that condition by default. Rather than passing an error message just add something to the Audit Log to advise that it tried to stop a stopped clock (or vice versa). As it is right now, adding those conditions AND having the flexibility of stop clock being user-set for certain circumstances, just seems to result in a needlessly complex-looking process when it could be accomplished by the addition of simple logic to the automatic/manual action to check for the status of the clock.