The spawn process is a sub-process that is started ad-hoc in the scope of an active process instance in runtime environment by users. These sub-processes cannot be specified at the time of workflow design. So a spawned sub-process behaves asynchronously with respect to execution at the time of:
For more information, please refer to the chapter Configuring Sub-process Activities of the Modeling Guide.
Stardust Process Portal is used to control and automate workflows in organizations. Previously, workflows have to be described as structured process models, where the sequence of steps and possible alternative paths are modeled. Also, the workflow is controlled according to these models at system runtime for a possible large number of business cases following the same model structure. In short, organizations have to follow the structured workflows.
However, for some organizations it is not feasible due to complexity of workflow and dependence on the provided data and documents. To model all necessary steps, possible execution paths and involved organizations; it is required to define and change these for a concrete business case during work on the same.
Stardust helps you to specify, manage and monitor ad-hoc work in addition to structured business process execution. It allows teams to work on business cases collaboratively without having a predefined structure for this work. It helps to improve:
The following organization scenario explains how Stardust can help you create ad-hoc process instances. Thus, supports unstructured workflow.
The SunBabel Corporation has recently implemented a Scan client to scan documents into Stardust Process Portal and start process instances. The Scanning implementation is generally regarded as a success but two issues have arisen that SunBabel has requested be addressed with new features in Stardust Portal.
This business case describes common usage pattern for the process instances that are spawned during the workflow processing. The spawning of a root process instance creates another sub-process of the same root process. The single document is available to all the spawned process instances.
This use case explains how the spawning of the process can streamline the operation.
With approximately 5% of scans, the scan operator selects the incorrect process in the Scan UI and the document enters the workflow in the wrong process definition. When these errors are discovered these process instances are aborted and the documents are rescanned into the correct process definitions. This can be time-consuming and has resulted in multiple fines when the processing SLA's were missed. SunBabel has requested enhancements to allow operators working in the Stardust Portal to move these Process Instances (PIs) directly to the correct process definitions. Also, any data associated with the documents should be moved to the new process instances.
SunBabel often receives work that contains multiple requests for a single client. Due to Auditing requirements, these documents must be scanned into Stardust as a single document and any additional process instances needed to work the client's requests should be started in the portal and referenced to this single document. SunBabel has requested enhancements that would allow operators in Stardust to spawn a process instance for each of these requests and have each process instance reference the original document. Additionally, these tasks should have a linkage so that business units can track these requests as a single entity.
For detail instructions, please refer to the tutorial Spawning Sub-processes of the Developers Handbook.