Summary
PreviouslyPrior to Version 3.3, when a new workflow definition was implemented in production, any in-progress live instances submitted beforehand were automatically updated on deployment to adhere to the new workflow design. However, this transition could This had the potential to lead to complications , especially with incomplete or missed tasks, due to discrepancies between the workflow definitions, potentially resulting in broken instances.To address this issue, we implemented with existing in flight workflows if the cut-over was not carefully handled.
To Provide choice and control over workflow changes, V3.3 implements a new process to isolate detach in-flight workflow instances from automatically adopting the latest FAB workflow changes introduced in production. Existing By default, existing instances in production will maintain their original workflow definition as assigned at the time of submission, ensuring continuityinflight workflows can complete without interruption or update. Similarly, new instances will seamlessly adopt the most recent available workflow definition, maintaining consistency across the project lifecycle. Lastly, the ability for prior instances to be updated to the latest version is made available in the Instance data report.
Auto-Versioning (FAB v3.3)
...
With the introduction of Non-Breakable Workflow design in FAB version 3.3, any modifications made to workflows in development now automatically trigger versioning. This results in the creation of a new workflow version each time changes to the WF definition are saved. While this ensures version control, it presents challenges during the development and testing phases where numerous modifications and test instances are expectedresult in many versions.
Moreover, tracking and monitoring the specific workflow version used at the time a form instance was created has become difficult.
...