Reasons to Avoid Deleting Case Objects

The best practice is to not delete case objects as part of a normal operation. If you do delete case objects, the best practice is to only delete using a single case reference from within a service task in a business process.

The primary reason to not delete case objects is that if there are other processes (other than the process performing the deletion) that have a reference to the deleted case object, those processes become halted and cannot proceed. In addition, case history (audit trail) is constructed using case objects; if those objects are deleted, the history is no longer available.

Therefore, case objects should not be deleted until it is known for certain that no other processes are referencing the object, and that the case history is no longer needed.

If you delete a case object using a single case reference from within a service task in a business process, built-in checking is provided for other processes that are referencing the case object. (You can catch the UnsafeToDeleteCaseError error code.)

Note: It is also possible to use the following methods to delete case objects, but these methods do not provide any error checking for other processes that are referencing the case object(s) that will be deleted. Using any of these methods could result in processes being halted because they are referencing a case object that no longer exists.
  • Using the "deleteCase" operations in the BusinessDataServices API.
  • Using a service task in a business process to delete:
    • multiple case objects using an array of case references.
    • a single case object using a case identifier.
  • Using a service task in any type of process other than a business process - for example, a pageflow process or service process - to delete case objects (by any method).

Deletion of case objects is controlled by a system action (Delete Case Data) that defaults to deny, therefore you must be explicitly granted the permission to delete case objects.

Related tasks