Processes in a ‘waiting’ state
When you add a User Interface to a business process in Process Platform, the default setting for that form is that it is a set as a task. This means that when you run the process, the BPM engine will send that task to the inbox and the process status changes to ‘Waiting’. When the task is picked up and completed, the process will continue. However: that is only the happy path! What should be done when nobody picks up the task or completes it?
Option one is to go into the properties of that task. There is a tab called ‘Duration’ that allows you to work with the timing elements of that task.
This allows you to set a specific start time of the task (the task will not appear in your inbox until after the time you specified) and also set the due time. The latter is used more often of course: you want to specify, perhaps based on an SLA, when this task should be completed. In both cases you have the option to set this time as a static duration, or to read the duration from a value stored somewhere in the message map. Note that in that case you need to specify this time in the XSD duration type format. E.g. if you want to specify that a task needs to be finished in two weeks, you would specify the value to ‘P14D’ or in case of two hours and 30 minutes to ‘PT2H30M’. Please be aware that you can also use business calendars for the calculation of the start and due date to be even more precise in setting the SLAs. By default nothing really will happen when the due date is not met: it will show in red in your Process Platform inbox only. You can change that by changing the values in the next tab: Escalation.
Another way of changing the way the process behaves when a task is overdue, is by using a ‘time-out’ on the activity (or, using an embedded sub-process, on a group of activities). You can use the same time settings (business calendars, static duration or read from message) to determine where the process should go if the task or set of tasks is overdue. Difference in behavior is that the task itself becomes obsolete and disappears from the inbox. This allows you to do more things than just simple warning people about overdue tasks and/or reassigning these tasks.
Last but not least there is the ‘Delay’ construct. That just puts a process in a waiting state. For example you want to make sure that the ordered goods have arrived at the customer before the invoice is sent. So in your process you will build a delay of three days after the shipping activity before you step into the next activity: the sending of the invoice. Or you give your customer the option to cancel their order within two hours after receiving the confirmation of the order: upon receipt of the confirmation you step into the cancellation process, else you will continue with the processing of the order.
Let me know which other topics you would like to see here!
