The life of a workflow process is pretty simple, it starts at a single start point and ends at a single endpoint or multiple endpoints.  It used to be the case that all workflows must end at a single endpoint, but its no longer the case.  Some of the legacy BPM products force you to have a “STOP” step, but newer products as FlowWright can have multiple endpoints.  Here’s a simple workflow with a single endpoint:

The above workflow will always end at the “Stop” step.  Here’s a workflow with multiple endpoints: 

The above workflow will always end with “Manager 3 approval and Manager 1 approval” or “Manager 3 approval and Manager 2 approval”.  Here’s the executed instance.

Some process analysts still use the “Stop” step to show all the endpoints of execution for a given workflow instance.  As life begins at the “Start” step, processes are persisted to the database until work needs to be done on the process.  The engine is notified through an engine alert to start processing the process from the start step.  Once the engine starts processing from the start step, it will keep processing until it finds a wait step.  Wait step could be any user interactive step such as a user task, or a non-interactive step such as a “Wait” step.

At this point the process will go to sleep, consuming zero resources and wait for an engine alert to start processing.  Typically, the engine alert create will identify a waiting step, and the engine is able to start processing from the waiting step.

Once the engine has no more steps to process, then workflow instance is set to completed status.  Then there sub-workflows, which can be synchronized or not synchronized.  If the sub-workflow, also known as child processes is synchronized, then the parent process will wait until the child process is completed before processing the next step in the parent process.  If the sub-workflow is not synchronized, then the parent process kicks off the child process and keeps processing the parent.