The warrant serving process is fairly uniform across different jurisdictions, although the lines of business that fulfill a given role vary. Additionally, situational factors (e.g., the location in which a subject is arrested) can also alter the process flow.
In particular, when a warrant subject is arrested outside of the Owning Entity’s jurisdiction (e.g., as the result of a warrant search performed during a traffic stop) the Arresting Entity must notify the Owning Entity of the arrest. In cases where the subject is arrested by the Owning Entity, the Owning Entity would also fulfill the role of Arresting Entity. As such, both of these scenarios are accommodated by a single process flow.
The process identifies the generic concept of a “Subscribing Entity.” It was determined that, when a warrant is served, 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 served 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 Serve Warrant Business Function:
Primary Flow
Serve Warrant-Primary (png)
Serve Warrant-Primary (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 Arresting Entity arrests a warrant subject. |
|
|
The Arresting Entity generates and sends a Warrant Served Message to the Owning Entity (typically Law Enforcement); this message includes any necessary details of the service such as date and time of service, location of service, arresting officer, etc. |
|
|
The Owning Entity adds any additional servicing information to the warrant. |
|
|
The Owning Entity generates and sends a Warrant Served Message to the warrant’s Issuing Entity. This message serves as notification of warrant service. |
|
|
The Owning Entity generates and sends a Warrant Served Notification Message to any Subscribing Entities. Which entities receive such notifications will depend on the type of warrant and jurisdiction. |
|
|
The Owning Entity generates and sends a Warrant Served Message to the Repository. |
|
|
The Repository processes the Warrant Served Message and marks the warrant as served. Note that the actual mechanics of marking a warrant as having been served will vary by implementation (delete from repository, set a flag, etc.) |
|
|
If necessary, the Repository submits the warrant service information to NCIC. |
The following table summarizes the responsibilities of each role depicted in the business process flow:
| Role | Responsibilities | Actors | ||||||||||||||||
|
Arresting Entity |
|
|
||||||||||||||||
|
Owning Entity |
|
|
||||||||||||||||
|
Issuing Entity |
|
|
||||||||||||||||
|
Subscribing Entity |
|
|