Currently, workflow definitions can contain workflow configuration panels that not just act as model for workflow properties (what workflow properties does the workflow definition support? what are there names, types and defaults?), but also as view (HTML representation) and controller (logic to set the properties).
While this is easy to do and very flexible, mixing up the model, view and controller has disadvantages:
There is, for example, no clean interface to read the list of workflow properties or to set the workflow properties out-side the configuration panel logic itself. The Admin UI, for example, needs to extract the properties from the view itself.
The goal of this task is to redesign the workflow configuration.
The workflow definitions only contain the model. Think of
<property id="publishToEngage" name="TRANSLATION_KEY" description="TRANSLATION_KEY" type="boolean" default="false">
It is not that simply as there are related properties, e.g. usually viewed as radio buttons, and other things to consider.