Process Model

Hi diyar185976 ,

Subprocesses are used to modularize reusable or independent logic, improve maintainability, and control execution behavior, while single process models are preferred for simple, tightly coupled flows where separation adds unnecessary complexity.

Let's break your question in to few points, just to understand quickly:

1. Reusability (biggest factor) - Breaks individual short processes, which can be reused, (E.g : Email Reminder with custom templates used in different stages)

2. Separation of concerns ( Keeps logic isolated and maintainable ) - E.g Main process = onboarding, Subprocess = background verification

3. Complexity control - E.g - Single process with 40 nodes → unreadable, where 5 PMs with few nodes

4. Independent execution (critical) - use Synchronous - back to back tasks, - Asynchronous, user creation even if related PM fails

5. Performance & execution behavior - Subprocess (synchronous) -> parent waits , Subprocess (asynchronous) -> runs independently.

Most developers:

1. Either dump everything in one process.

2. Or overuse subprocess everywhere.

Both are wrong, always go with modular design ensuring all the above mentioned points.

FYI - Please check documentation to know more about Subprocess - docs.appian.com/.../Sub-Process_Activity.html

Much of what Varun already wrote above is pretty on-point.  I would offer my simpler take: it's not "either-or", and there is no "strictly right answer".  Often what happens is a process evolves over time and you realize that certain sections represent functionality you'd rather have reusable across different processes (without having to rebuild it over and over again, and without the risk that it drifts apart in functionality), so you encapsulate those pieces into a subprocess.  I do wish the process of accomplishing this were a little bit faster or more painless, but I don't know what's feasible.

Mike/Varun have some excellent points. Here is an additional resource with some information you might find useful: 

community.appian.com/.../how-to-create-memory-efficient-models

Use subprocesses when logic is reusable, independently testable, or makes the main process too complex to read.
Keep everything in a single process when the flow is simple, linear, and not reused elsewhere.
A good signal for a subprocess is if it represents a distinct business function like approvals or notifications.
When in doubt, prefer a single process first and extract subprocesses only when complexity demands it.

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.