Scope
APEX 23.2 introduced Workflow as a native component specifically aimed at modeling and executing business processes. The following release, APEX 24.1, introduced several enhancements like the availability of the Workflow Diagram at run-time, Archive/Purge enhancements and so on. For users new to APEX workflow, the following blogs introducing the concept of APEX workflow would be a helpful pre-read, before proceeding with this blog:
Simplify Business Process Management using APEX Workflow
Multi-Level Expense Approval Using APEX Workflow
Why use workflows within a workflow?
Allowing a workflow to be invoked from another workflow has manifold benefits.
- Manageability – Breaking down complex businsess processes into smaller, manageable chunks that can be invoked from the parent workflow, keeps the process clean and easy to comprehend. Employee onboarding is a great example where the main workflow can comprise of smaller distinct workflows like Purchase and Requisition , HR- tasks, Departmental tasks, Training etc.
- Reusability – Common tasks can be clubbed together into a single workflow that can be reused by other workflows. Typical examples are credit-worth computation of an individual. Such a workflow can be reused by different workflows, like a) Hospitalization Process, b) Home Loan approval process, c) International Travel approval, and so on.
APEX – Invoke Workflow Activity
Release 24.2 introduces the Invoke Workflow activity – a special activity that can be used in a workflow to call a different workflow.
As the figure below shows, the Invoke Workflow Activity appears along with other activities in the Activities Palette at the bottom of the Diagram Builder pane of the Workflow Designer and can be dragged and dropped into the workflow diagram.
 .
. 
The following figures show how the Budget Approval workflow can be invoked as part of the Laptop Request Workflow and the different settings available for an Invoke Workflow activity.

Figure 1 Parent Workflow – Laptop Approval

Figure 2 Invoked Workflow – Budget Approval
Parent Workflow guidance
Note the parameters on the expanded Invoke Budget Approval activity in the tree region of the left pane. Employee ID and Item are inputs passed on from the Laptop Request Workflow to the Budget Approval Workflow. Status is an output that the Budget Approval Workflow passes back to the Laptop Approval workflow. Depending on the Status passed, the laptop request is either approved or rejected.
The right hand pane shows the Invoke Workflow settings in the Property Editor:
Workflow Definition : This is a dropdown where the workflow to be invoked is selected. In this example, the Budget Approval Workflow is selected. Validation errors are raised if you attempt to select the same workflow as the current workflow, or if you attempt to select a workflow that is a parent of the current workflow. This eliminates the risk of a cyclic dependency being introduced in the business process.
Initiator Item: You can select a parent workflow variable that designates the initiator of the invoked workflow. If left empty, the initiator of the parent workflow automatically becomes the initiator of the invoked workflow.
Details Primary Key Item: If the invoked workflow has additional details specified, then this item specifies the value of the primary key of the additional detail record associated with the invoked workflow. In this example, the Budget Approval Workflow (shown in the Figure 2), has table EBA_DEMO_APPR_BUDGET specified as the additional detail with EMPLOYEE_ID as the Primary Key column. The Detail Primary Key in Figure 1 thus points to the Employee ID value that uniquely identifies a row in the EBA_DEMO_APPR_BUDGET table.
Workflow ID Item: One can select a workflow variable that will store the value of the invoked workflow instance ID.
The next two settings are of particular interest in the context of an Invoke Workflow activity
Wait for Completion : This switch determines whether the parent workflow will wait for the completion of the invoked workflow, before it progresses to the next activity. In our example, as shown in Figure I, the Wait For Completion switch is on. This means that the Budget Approval Workflow needs to complete before processing continues for the Laptop Request Workflow. When this switch is turned off, it is a fire and forget invocation. The parent workflow simply invokes the specified workflow and proceeds to the next activity. The invoked workflow and parent workflow execution are forked at this point and there is no dependency between the two flows from this point onwards. Whether this switch is turned on or off completely depends on the business usecase.
Retry Point: This is a dropdown with two values- Resume and Start Over. 
 Here’s a bit of context. When the invoked workflow encounters a fault, and Wait for Completion is set to true, then the fault is propagated to the parent workflow. At this point, the Workflow Administrator or Owner can retry the parent workflow. If the Retry Point is set as Resume, then the invoked workflow instance is retried from its faulted activity. If the Retry Point is set as Start Over, then the invoked workflow instance is terminated, and a new instance of the invoked workflow is created. The Retry Point setting depends on the business usecase. Fault mitigation requirements vary from business to business, For some atomic workflows, it makes more sense to start afresh after a fault, whereas for others, it is feasible to fix the faulted activity and resume the existing instance.
Seamless navigation between parent and invoked workflows
The Workflow Designer allows easy and intuitive back and forth navigation between the parent and invoked workflows. To open the invoked workflow model/definition from the parent workflow, simply click on the Open context menu entry on the invoked workflow activity. To go back to the parent workflow model/definition, click on the Back button in the diagram builder toolbar region. The diagrams below illustrate the experience.
 .
. 
Parameter Directions
With the support for invoked workflow, Release 24.2 also allows parameter directions (In, Out, In/Out) to be specified as part of defining workflows. In the Budget Approval Workflow, the Status parameter is specified as In/Out. In the Invoke Budget Approval of the parent (Laptop Request) workflow, the Status parameter is mapped to the V_TASK_OUTCOME workflow variable.
 
 
What this means is that the V_TASK_OUTCOME variable value is passed from Laptop Request Workflow to the invoked Budget Approval Workflow. In the invoked workflow, the Status value after being processed, is returned to the Laptop Request Workflow via V_TASK_OUTCOME variable.
Note: When the Workflow is used in a Workflow – Start page process, the Out parameters are not shown. This is because the workflow, once submitted from a page, runs asynchrously and out parameters can not really be returned to the page. Therefore, Out parameters are only relevant in the context of Workflows being used in Invoke Workflow Activity.
Runtime Experience
At run-time, when the Laptop Request is raised for an employee, and the Laptop Request Workflow begins executing, at one point it reaches the Invoke Budget Approval activity. This is when the initiator sees two workflows in the Workflow Console.

Notice the underlined Invoke Budget Approval activity in the Laptop Request Workflow Details page on the right. Clicking on the activity opens the invoked workflow details as shown below.

The details page for an invoked workflow has an additional button (To Parent Workflow), at the top to return to the details of the parent workflow.
This helps in seamless back and forth navigation between the parent and invoked workflows at runtime.
Copying a workflow from another Application
Another significant enhancement offered in release 24.2, is the ability to copy a workflow from a different application. With this feature in place, standardized workflows that form a template for customization can be copied from the base application into the custom application, and then be edited as per the business requirement. This saves developer hours, and reduces the risk of implementation errors. When a workflow is copied over from a different application, any other shared component, like Email Template(s), Human Task(s), REST Data Source(s) which is used by the workflow, is also copied over to the target application. If the workflow being copied has an Invoke Workflow activity, then the invoked workflow is also copied over to the target application
The Copy From Other App option is available in the Workflow Reports page which is opened from Shared Components-> Workflow and Automation-> Workflows.

In this example, when the Laptop Request workflow is copied over, it will automatically copy over the Budget Approval Workflow as well, since it is invoked by the Laptop Request workflow.

Conclusion
Declarative invocation of workflows from other workflows is a powerful enhancement that will make modeling of business processes more robust and reduce redundancy. The ability to copy workflows from other applications is also expected to be be a productivity boost for app developers .
I hope the readers of this blog will experiment with these two exciting new enhancements in APEX workflow and provide us with their feedback and ideas to make APEX Workflow even more powerful in the coming releases.
