Three common scenarios for issuing warrant updates have been identified. The distinction among these three scenarios lies in the process used for distributing information about warrant updates.
In the first scenario, an Issuing Entity notifies the Owning Entity that a warrant has been updated 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 updated 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.
Note that all three of these processes support updates that require screening and/or approval as well as updates that do not require screening or approval. In the former case, the process is initiated when an Issuing Entity receives a Warrant Update Message from an Approving Entity as depicted in the "Request Warrant Update" process. The later scenario is triggered when an Owning Entity wishes to make a warrant update that does not require screening or approval.
The process identifies the generic concept of a "Subscribing Entity." It was determined that, when a warrant is updated, 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 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 type of warrant update. Other implementations may have no need for such notifications.
The following links provide Business Process Flow Diagrams for the Warrant Update Business Function:
Primary Flow
Warrant Update-Primary (png)
Warrant Update-Primary (bpm)
Alternate Flow 1
Warrant Update-Alternate 1 (png)
Warrant Update-Alternate 1 (bpm)
Alternate Flow 2
Warrant Update-Alternate 2 (png)
Warrant Update-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 Update Message from an Approving Entity (Court) indicating that a warrant is to be updated. |
|
|
The Issuing Entity generates and sends a Warrant Update Message to the Owning Entity (Law Enforcement) that is responsible for maintaining and servicing the warrant. |
|
|
The Owning Entity generates and sends a Warrant Update Message to the Repository. The Repository processes this message and updates the warrant in the repository. |
|
|
If necessary, the Owning Entity generates and sends a Warrant Update Notification to any Subscribing Entities. Which entities receive such notifications will depend on the type of warrant update and jurisdiction. |
|
|
If necessary, the Repository submits the updated warrant information to NCIC. |
Alternative Flow 1 Description
|
|
An Issuing Entity (Court, Court Clerk) receives a Warrant Update Message from an Approving Entity (Court) indicating that a new warrant is to be updated. |
|
|
The Issuing Entity generates and sends a Warrant Update Message to the Repository. The Repository processes this message and updates the warrant in the repository. |
|
|
The Repository generates and sends a Warrant Update 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 Update Notification to any Subscribing Entities. Which entities receive such notifications will depend on the type of warrant update and jurisdiction. |
|
|
If necessary, the Repository submits the updated warrant information to NCIC. |
Alternative Flow 2 Description
|
|
An Issuing Entity (Court, Court Clerk) receives a Warrant Update Message from an Approving Entity (Court) indicating that a warrant is to be updated. |
|
|
The Issuing Entity generates and sends a Warrant Update 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 Update Notification to any Subscribing Entities. Which entities receive such notifications will depend on the type of warrant update and jurisdiction. |
|
|
The Repository processes the Warrant Update Message and updates the warrant in the repository. |
|
|
If necessary, the Repository submits the updated warrant 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 |
|
|