Page History

...

Dynamic processes are processes in which not all possible scenarios are completely delineated upfront. In dynamic processes there is no diagram, model or code available that tells us which possible scenarios can occur and what to do when in each scenario. In stead of meticulously connecting activities to establish completeness in flow, in dynamic processes all activities can in theory attribute to the process. For each activity that is part of the process, a precondition simply states when the activity can be performed. Such a precondition is a boolean statement that makes use of the available data, the artifacts in the system and the state or phase the process is in. A dynamic process engine (like Blueriq) will decide at runtime which activities can and must be performed at any given moment in the process. In Blueriq, dynamic preconditioned activities are modeled as ad-hoc tasks.

From a Blueriq - point-of-view, it is not mandatory to use preconditions and ad-hoc tasks exclusively, nor is it mandatory to use flow exclusively. One of the unique aspects of Blueriq is that both approaches are available and can be intertwined to get the best of both worlds. So whenever there is an activity that may only be performed when another activity is completed, it can be modeled with flow.

...

However, in business processes it is very uncommon that all activities can be applicable throughout the entire process. At a certain point (in dynamic case managment management terms: when a certain milestone is reached), some activities are simply not part of the process anymore. Or not part of the process yet. This is why business processes can be dissected into phases. Using phases, milestones, ad-hoc tasks and preconditions will result in really dynamic and flexible business processes, without the downside of delineating all scenarios upfront and connecting the activities with all possible paths.

...

Most processes are - from a high point of view - very linear. So is our example: it consists of the sequential phases Apply, Pay, Decide, Register. In the vast majority of business processes, the phases are singular and linear, meaning a case or process will always be in one phase and after that phase, another phase will follow. When during the design of phases it turns out that many phases can be applicable at once and many different phases might follow a phase, the granularity of the phase is probably off: you are most likely designing tasks/activities in stead of phases.

Sometimes however, a phase can be skipped. In this particular example, when registration is rejected on grounds of inadmissibility, the phase registering is skipped right after decidingaltogether. The rejection because of inadmissibility is done when the application is not complete or documents are not valid and the applicant is has not been able to provide the necessary information. When the application is complete and all documents are valid, registration could still be denied. This is because Denying and rejecting sound alike, but differ in this example. Denying an application is done when the application is not eligible, although complete and valid. Non-eligible applications are registered as well as eligible applications, but with a negative decision. Rejections, as mentioned before, are not registered at all.

...

Sometimes there are tasks that are always available. In this example, it is always possible to register some sort of contact between applicant and the back office, for instance by mail or telephone or in person. This is done using an ah-hoc (Image Added) task that is also a repeatable task () and has no precondition (Image Added) throughout the process. In Blueriq, an ad-hoc task without a precondition throughout the processis modeled with a precondition that is always true.

Life events

Events such as relocation or death of the applicant or, in other cases divorce or unemployment, will trigger the process from outside. For these life events, message events are used.

...