Process Model

I also like to use subprocesses for any logic that I want to take effect for running instances, as well as new, as soon as the code change is deployed.  This is especially helpful in 'longer running' processes, but also comes in handy for some quicker processes.

Email notifications is one scenario - we find the business often updates email instructions or directions, etc, where you want ALL new notices to contain the new verbiage.  If the notification is at the end of your parent process, legacy instances will continue to send the legacy notices, unless they are configured via subprocess.

Other than email notices, audit doc creation, etc, we primarily use subs to separate logic for process model sizing and cleaner development.  

While I do regularly have subprocess re-used / re-called within the same process model (think, audit doc update that is called each time the process progresses), it is much more rare that we have a subprocess shared between separate applications.

I also like to use subprocesses for any logic that I want to take effect for running instances, as well as new, as soon as the code change is deployed.  This is especially helpful in 'longer running' processes, but also comes in handy for some quicker processes.

Email notifications is one scenario - we find the business often updates email instructions or directions, etc, where you want ALL new notices to contain the new verbiage.  If the notification is at the end of your parent process, legacy instances will continue to send the legacy notices, unless they are configured via subprocess.

Other than email notices, audit doc creation, etc, we primarily use subs to separate logic for process model sizing and cleaner development.  

While I do regularly have subprocess re-used / re-called within the same process model (think, audit doc update that is called each time the process progresses), it is much more rare that we have a subprocess shared between separate applications.