Three common scenarios for issuing warrant recalls were identified. The distinction among these three scenarios lies in the process used for distributing information about recalled warrants.
In the first scenario, an Issuing Entity notifies the Owning Entity that a warrant has been recalled and the Owning Entity distributes this information to other interested parties. In the second scenario, the Issuing Entity notifies the Repository that a warrant has been recalled and the Repository distributes this information to other interested parties. In the third scenario, the Issuing Entity notifies both the Owning Entity and Repository simultaneously and these entities distribute the information to other interested parties.
The process identifies the generic concept of a “Subscribing Entity.” It was determined that, when a warrant is recalled, any number of entities may need to receive a notification. Because there is considerable jurisdictional variation in the routing of such notifications, this model does not specify the lines of business that might receive a warrant recall notification. As an example, an implementation may choose to send these notifications to involved parties (Requesting Entity, Screening Entity, etc.) based on the content of the warrant or the reason for the recall. Other implementations may have no need for such notifications.
The following links provide Business Process Flow Diagrams for the Warrant Recall Business Function:
Primary Flow
Warrant Recall-Primary (png)
Warrant Recall-Primary (bpm)
Alternate Flow 1
Warrant Recall-Alternate 1 (png)
Warrant Recall-Alternate 1 (bpm)
Alternate Flow 2
Warrant Recall-Alternate 2 (png)
Warrant Recall-Alternate 2 (bpm)
The sample process flow diagram was developed in standard Business Process Model and Notation using the Windows-based Bizagi Modeler tool and can be modified to represent the specific process in your jurisdiction. To download a free copy of the Bizagi Modeler tool, go to bizagi.com.
| Primary Flow Description | |
|
|
An Issuing Entity (Court, Court Clerk) receives a Warrant Recall Message from an Approving Entity (Court) indicating that a warrant is to be recalled. |
|
|
The Issuing Entity generates and sends a Warrant Recall Message to the Owning Entity (Law Enforcement) that is responsible for maintaining and servicing the warrant. |
|
|
The Owning Entity generates and sends a Warrant Recall Message to the Repository. The Repository processes this message and marks the warrant as recalled. Note that the actual mechanics of marking a warrant as having been recalled will vary by implementation (delete from repository, set a flag, etc.) |
|
|
If necessary, the Owning Entity generates and sends a Warrant Recall Notification to any Subscribing Entities. Which entities receive such notifications will depend on the type of warrant and jurisdiction. |
|
|
If necessary, the Repository submits the warrant recall information to NCIC. |
Alternative Flow 1 Description
|
|
An Issuing Entity (Court, Court Clerk) receives a Warrant Recall Message from an Approving Entity (Court) indicating that a warrant is to be recalled. |
|
|
The Issuing Entity generates and sends a Warrant Recall Message to the Repository. The Repository processes this message and marks the warrant as recalled. Note that the actual mechanics of marking a warrant as having been recalled will vary by implementation (delete from repository, set a flag, etc.) |
|
|
The Repository generates and sends a Warrant Recall Message to the Owning Entity (Law Enforcement) that is responsible for maintaining and servicing the warrant. |
|
|
If necessary, the Repository generates and sends a Warrant Recall Notification to any Subscribing Entities. Which entities receive such notifications will depend on the type of warrant and jurisdiction. |
|
|
If necessary, the Repository submits the warrant recall information to NCIC. |
Alternative Flow 2 Description
|
|
An Issuing Entity (Court, Court Clerk) receives a Warrant Recall Message from an Approving Entity (Court) indicating that a warrant is to be recalled. |
|
|
The Issuing Entity generates and sends a Warrant Recall Message to the Owning Entity (Law Enforcement) that is responsible for maintaining and servicing the warrant as well as the Repository. |
|
|
If necessary, the Owning Entity generates and sends a Warrant Recall Notification to any Subscribing Entities. Which entities receive such notifications will depend on the type of warrant and jurisdiction. |
|
|
The Repository processes the Warrant Recall Message and marks the warrant as recalled. Note that the actual mechanics of marking a warrant as having been recalled will vary by implementation (delete from repository, set a flag, etc.) |
|
|
If necessary, the Repository submits the warrant recall information to NCIC. |
The following table summarizes the responsibilities of each role depicted in the business process flows:
| Role | Responsibilities | Actors | ||||||||||||||||
|
Requesting Entity |
|
|
||||||||||||||||
|
Issuing Entity |
|
|
||||||||||||||||
|
Owning Entity |
|
|
||||||||||||||||
|
Subscribing Entity |
|
|