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 it's 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 in 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.  The 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 a “Sleeping” state, consuming zero resources, and wait for an engine alert to start processing.  Typically, the engine alert created will identify a waiting step, and the engine can start processing from the waiting step.

Once the engine has no more steps to process, then the workflow instance is set to completed status.  Then there are 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.