Workflows

Workflows are the concept to describe the flow and execution of work in a NS application. It is important to have a well-defined state for all elements which are processed by an application. At any point in a process something can go wrong and if it does, we need to know exactly what to do to resolve it. For this reason, workflows are explicitly modeled as a state-machine.

Historically workflows have been part of the runtime configuration of our applications. These were stored and maintained in the database. The business processes which we define however are part of the development cycle. This means small changes in the business process require updates to the database. Meanwhile, authorized users of the application might have changed the configuration without the developer knowing. As a result, the actual workflow configuration becomes less predictable and more difficult to test in a representable manner.

The workflow metamodel aims to solve this by moving your workflow definition right into the application model. This has multiple advantages. It becomes much more apparent what the application is supposed to do. Having this information in the model means we can create visualizations and expand artifacts based on it. This not only increases visibility in the model but also helps with clarity in the expanded code, where a database configuration has to resort to generic and dynamic code in order to function accordingly.

In addition the workflow metamodel introduces the concept of triggers. They will allow fine-grained access to each transition and remove the restriction of only using workflow engines for performing work. This provides us with a framework in which we can be much more explicit about when and why a transition should be performed. Examples include but are not limited to receiving external requests, creating a dataElement or having a timeout which expires.

This model allows us to do much more innovation in the workflow back-end, since we are no longer restricted by runtime configuration. It was designed with backwards compatibility in mind, which means you can start using it directly by migrating existing applications using the workflows-importer.