Intalio BPM - Intermediate Timers and Task Management

Use Case: Police electronically file a criminal complaint in which a summons is issued and the defendant has not been processed (electronically fingerprinted with LiveScan and Photographed). The Chief law enforcement officer of the jurisdiction wants to be able to track fingerprint compliance to monitor who has and who has not been processed. In the current model, we are able to capture those defendants who have been processed, but have no way of updating the KPI dashboard on fingerprint compliance for those who have not been fingerprinted once the complaint has been electronically filed with the Court.

Proposed Solution: Using BPM, extend the current model to track those defendants not processed and incorporate any rules of criminal procedure within the process that pertain to fingerprinting following the issuance of a summons.

In the diagram below, a message is received after electronically filing a criminal complaint if the defendant was not processed. A task is sent to the officer filing the complaint - 'Fingerprint Pending'. Since the defendant has 5 days to report for processing, an intermediate timer between the creation of the task and the completion of the task is set to 5 days and 1 minute. An intermediate timer placed on the sub process is set to 5 days. If the defendant reports for fingerprinting within the court ordered time frame of 5 days, the officer will complete this task and the Key Performance Indicator (KPI) for the fingerprint compliance dashboard will be updated. However, if 5 days passes and the task is not completed by the officer the following occurs:

1. The task is deleted from the officer's task list. This is accomplished by calling two (2) different services within Intalio - task manager service and token service. In the task manager service, there is an operation called delete and this operation will delete a given task. The delete operation takes two (2) parameters, taskID and participantToken. The taskID is obtained within the process from the create task response message. The participantToken has to be retrieved using the Token Service. The token service takes two parameters, username and password. The administrator account has the authority to delete a task so those values are passed into the service. The response message from the token service provides the participantToken which can be passed into the delete operation. This will then delete the task from the officer's task list.
2. In case the officer forgot to complete this task, and the defendant was fingerprinted, we send an email from the process using an email web service informing the officer that this task was deleted and if the defendant was fingerprinted to contact the District Attorney's office immediately before bail revocation documents are forwarded to the Court.
3. A task is sent to the District Attorney's office informing them that Bail Revocation may be required due to non-compliance with a fingerprint order as a condition of bail. If the DA determines from their own investigation or from the officer that the defendant was processed, they can enter the name of the booking center and the KPI will be updated and reflected in the fingerprint compliance dashboard. If the defendant was not processed, information retrieved from the complaint can pre-populate a bail revocation web form to reduce redundant data entry. Any additional information required may be entered by the District Attorney staff. A pdf of the bail report can be printed from the web form and submitted to court. In the future it is possible that the document be electronically submitted to the court.
4. Finally, the KPI is updated to reflect that a bail revocation has been filed on this defendant.

Below is a diagram of the proposed work flow.

Diagram:

















More info at http://btmsoftwaresolutions.com