Morphing processes at run-time is a complex feature within our workflow product that allows users to create Dynamic Sub-workflows.  FlowWright is currently one of the only products on the market that can do this.  The real-world example below might sound familiar.

A Natural gas company needs to have a workflow that tells meter readers to read what meters are within a certain location (address), and then the workflow needs to process the information from the meter read.  But, here's the problem, each location might have a different number of gas meters.  A single-family home will only have 1 gas meter, but a 4-unit apartment complex will have 4 meters. So, how can you build a workflow process where until the run-time of that process you won't know how many gas meters are there?  

Most of the time a workflow instance is an identical copy of the workflow definition, the process design is 1:1 where the workflow instance contains more run-time execution information.  But, given the above scenario, the structure of each workflow instance will be different because of the number of meters at each location. So, how do you solve this challenge? 

The solution is a Dynamic Sub-workflow.  This feature within FlowWright will make the workflow instance morph at run-time based on the number of gas meters.  So, when the workflow definition is built, it's defined with a single path using the "Dynamic sub-workflow" step, as shown below:

This workflow process is defined using a single "Read Meter" dynamic sub-workflow step, but at run-time, the process will automatically morph to the following: (*using data assuming there are 4 gas meter reads)

As you can see from the above diagram, at run-time the process has morphed based on the number of gas meters at the location.  Dynamic sub-workflow is a complex concept that applies to specific use case scenarios.  FlowWright can handle this scenario very easily, only a next-generation workflow product can do such morphing of workflow processes.