End of Process Life Cycle

The process life cycle begins in one of the K2 Designers from where the process definition is deployed to the K2 Server. During the life cycle there will be instances of the process which will be completed, go into error or some that are never completed. There may be dependencies such as SmartObjects or reporting that relies on the data generated by the process. There will also be data stored in the K2 Database and log data in log files. Also, since process definitions are often updated and redeployed to suit changing organizational needs, there may be multiple versions of the original process and all the associated data and dependencies that go along with it.

From the above description, it is evident that deleting a process definition goes beyond just removing a few files or a reference to an existing resource. Removing a process definition can have far reaching effects on a system and can impact on seemingly unrelated sections of K2.

On the outset, although every effort has been made to ensure that the Process Deletion functionality is able to scope the relevant dependencies; due to the diverse nature of these dependencies it is simply not possible to track all dependencies. As a result, if the user sees a notification popup indicating a warning then caution should be exercised before deleting the process. In terms of deleting a process and its dependencies successfully, the best asset is the person; designer or Administrator, who has experience working with the process.

Deleted Process Dependencies

The Process Deletion UI does provide a list of dependencies, this should be treated as a guide and not an absolute reference of what will be affected i.e. some item may have been omitted.

When the process is deleted there are default items which are deleted namely the process definition, process instances and associated data. For processes that have a higher level of association and integration, certain aspects of these dependencies would either not be traceable or the process deletion functionality may not be able to remove it.
In some instances, owing to regulatory requirements the user may not want certain data elements to be deleted. However, if they are the onus would be on the user to ensure that they have been backed up.

Here is a list of what will be deleted for a Process definition by version; i.e. the process dependencies namely

Process Version with instances
IPC up to 1st level
- Child processes that have never been called may not appear
Reporting SmartObjects
SmartObjects with an association to Reporting SmartObjects (Note: This only takes place if the Reporting SmartObject is deleted as well)
Event Bus Constructs / Notifications (Note: This dependency is queried by process name only)

Supported Process Types

The following process types can be deleted using the Process Deletion feature along with the associated dependencies. The information serves merely as a guideline and does not attempt to cover all possible scenarios or dependencies.

	Standard process	SmartObject Process	SharePoint Integration	InfoPath Integration
Process Instance	Yes	Yes	Yes	Yes
Process Data	Yes	Yes	Yes	Yes
SmartObjects	Yes	Yes	Yes	Yes
Reporting SmartObjects	Yes	Yes	Yes	Yes
IPC	Yes¹	Yes¹	Yes¹	Yes¹
InfoPath Forms	No - Delete Manually	No - Delete Manually	No - Delete Manually	No - Delete Manually
SharePoint Site Deployment	No - Delete Manually ²	No - Delete Manually ²	No - Delete Manually ²	No - Delete Manually ²
Only the first level may surface as a dependency and only if a running instance(s) are active If for example an InfoPath process has been deployed to a SharePoint list and the process is deleted, the process will remain listed on the SharePoint List and when a user attempts to start a process, an error message will display

Considerations for Process Deletion

IPC Processes

When configuring the Child IPC, the user has the option of configuring the process as Synchronous or Asynchronous. Depending on the selection, the following outcomes will take effect when the process dependencies are determined.

Synchronous: Dependencies can be determined as the outcome of the parent process is dependent on the outcome of the IPC Child - provided at least one process instance is active or was fired previously
Asynchronous: Since the parent process does not rely on the outcome of the child, there is no link between the two and dependencies may not be shown.