Exception handling in
workflows

As we mentioned before, the issue of exception handling in workflows is a growing area of concern and research within the workflow community. But such problem can be better addressed in this logic framework.

First it must be noticed that this logic framework is much more flexible than standard workflow languages. The process specification in the logic formalism usually does not preclude other activities form being performed. What is important is that the workcase be consistent with the process specification, and not a instance of it in the standard workflow semantics. Thus if a non planned meeting is needed, it can be called, provided it is consistent with process, constraints and policies. Under the logic framework, the specifications can be seen as an envelope that limits the range of variability of the workcase.

But exception handling may involve not only executing unplanned activities but violating some of the procedures, constraints, and policies. For example in a particular case it may be decided that in order to get the results in time one can call a meeting with less than three days of advance. This means that to deal with this exceptional case one is willing to go outside the bounds of the envelope set by the specifications.

The balance of control and flexibility for exception handling can be modeled as a set of formulas $F_0, F_1, F_2, \ldots F_N$, which states different levels of exceptionality. F₀ is the process and policies for normal (standard, unexceptional cases). F₁ may represent the process and policies for a first level of exceptionality, F₂ for a second level of exceptionality, and so on. F_N represents the last level of exceptionality, that is the processes, and policies that cannot be violated in any case.

A particular workcase wc may be declared or perceived as exceptional and instead of following the standard process model F₀, it may follow F₁. That is, we require that $wc, \hat{t}\;\sim\;F_1$ and not $wc, \hat{t}\;\sim\;F_0$ as we require for ``standard'' workcases. Of course, to be able to deal with the exceptionality of the case, F<sub>1</sub>must be less constrained than F<sub>0</sub>, or in intuitive term, must be a larger envelope than F<sub>0</sub>. In general one would ask that $F_0 \rightarrow F_1$, that is, that the set of policies and procedures for the exceptional case be a ``logical'' subset of the standard set of policies. In F₁, some constraints that are required in F₀ are no longer required, such as the demand for a three day interval between the call for a meeting and the meeting itself.

Similarly in general one would ask that $F_1 \rightarrow F_2 \rightarrow\ldots \rightarrow F_N$, F_N being the core of the organization's policies. Thus different than other solutions to the problem of flexibility of workflows, this logical solution allows for modeling the constraints and policies to deal with different levels of exceptionality: if a good customer requests urgency for an order, one is allow to circumvent some of the standard procedures, if the best customer requests urgency for an order more of the standard procedures may be circumvented. But if parts or pieces of the procedures are dictated by law and verified by government agencies, those pieces of the process cannot be changed. In our terms, these ``pieces of the procedure'' are subformulas that are stated in all process specifications F₀ to F_N.