How to evaluate an RMS for a Texas law-enforcement agency.

A practical guide to evaluating records management systems for Texas police departments and law-enforcement agencies.

Choosing a records management system is not just a software decision. An RMS becomes part of how an agency documents incidents, reviews reports, manages investigations, maintains records, completes required reporting, and preserves years of operational history.

For a Texas agency, the evaluation also has to account for state reporting requirements, CJIS security requirements, data conversion, implementation, and what happens after go-live.

The best RMS is not necessarily the one with the longest feature list.

It is the one that can support the way your agency actually works while maintaining a dependable record underneath it.

This guide provides a practical framework for evaluating one.

Start with the work, not the feature list

Most RMS demonstrations eventually turn into feature tours.

Before looking at screens, write down how work actually moves through your agency.

A typical incident might begin with a call for service, move to an officer, become a report, require supervisor review, get assigned to an investigator, produce evidence or a warrant, and eventually become part of state reporting.

Your RMS should support that progression without forcing users to continually reconstruct what happened.

During a demonstration, ask the vendor to show a complete operational scenario, not isolated features.

For example:

A disturbance call comes in. Patrol responds. An officer creates an incident report involving two people and a vehicle. Evidence is collected. A supervisor rejects the report for correction. The officer resubmits it. The report is approved and assigned to an investigator. The investigator adds a supplement and obtains a warrant. Records later completes the required reporting.

Then watch what happens.

How many times is the same information entered? Does the investigator inherit the work patrol already completed? Can the supervisor tell what needs attention? Can you reconstruct the history six months later?

Those questions often tell you more than a 100-item feature checklist.

1. Define what the RMS will be responsible for

Before comparing vendors, establish what you expect the RMS to own.

Depending on the agency, that may include:

• Incident and offense reports
• Supplements
• People and organizations
• Vehicles
• Property
• Arrests
• Warrants
• Investigations
• Evidence/property records
• Citations
• Supervisory review
• Records-management functions
• Documents and attachments
• State and federal reporting
• Audit history

Then identify which other systems must work alongside it:

• CAD
• Mobile/field reporting
• Electronic citations
• Evidence systems
• Jail
• Municipal or justice court
• TLETS/TCIC/NCIC access
• Payment systems
• Document management
• Other local or regional systems

This gives you the boundary of the system you’re actually buying.

Ask the vendor

What is the authoritative record for each type of information?

If a person appears in a call, report, citation, arrest, and investigation, for example, determine whether those are disconnected copies or different uses of a shared person record.

2. Follow one record through the operation

An RMS should do more than store completed reports.

Evaluate what happens between creation and final disposition.

A useful demonstration should include:

Draft → submission → supervisory review → correction → approval → investigation/follow-up → records/reporting

Ask the vendor to demonstrate:

• An officer starting a report
• Adding people, vehicles, property, offenses, narratives, and attachments
• Submitting the report
• A supervisor reviewing it
• Rejecting it with instructions
• The officer correcting and resubmitting it
• Approval
• Assigning follow-up
• An investigator continuing the case
• Adding supplemental work
• Viewing the complete history afterward

Pay particular attention to whether each role can see what still needs work.

An agency does not operate as a filing cabinet. Its software should not either.

3. Look for shared records instead of duplicate entry

Duplicate data entry is one of the easiest problems to spot during an evaluation.

Suppose dispatch already captured:

Jane Smith

123 Main Street

Blue Ford F-150

Texas ABC1234

When the officer begins the incident report, what happens?

If the officer has to type everything again, ask why.

The same question applies when an incident becomes an investigation, an arrest produces a booking, or a citation moves into court.

Not every system or record should be the same. But information that is already known should remain useful when the work moves forward.

Test this during the demo

Ask the vendor to create a person once and then use that person in several different records.

Look for:

• Duplicate detection
• Master records
• Aliases
• Addresses
• Contact information
• Identifiers
• Vehicles
• Related incidents
• Citations
• Arrests
• Warrants
• Associations

Then ask what happens when information changes.

You want both useful current information and historical integrity.

4. Evaluate the officer experience

An RMS can satisfy administrative requirements and still be miserable for the people entering the information.

Have actual officers participate in the evaluation.

Ask one to complete a realistic report while everyone else watches.

Look at:

• Number of screens
• Number of required clicks
• Repeated fields
• Keyboard usability
• Search
• Autofill
• Code selection
• Narrative entry
• Attachments
• Validation
• Saving drafts
• Returning to unfinished work
• Mobile/laptop behavior
• Performance on the equipment officers actually use

Then ask a simple question:

Would you want to write reports in this every shift?

Do not underestimate this part of the decision.

Bad field usability eventually becomes a records problem because the RMS depends on officers entering complete and accurate information.

5. Evaluate supervisory review

Supervisors need more than an Approve button.

Ask how a supervisor determines:

• Which reports are waiting for review
• How long they have been waiting
• What changed after a rejection
• Why something was rejected
• Whether required information is missing
• Which reports need follow-up
• Whether an investigation has stalled
• Who currently owns the work

Also ask what happens after approval.

Can an approved record be changed? By whom? Is the original value preserved? Is the change audited? Does an amendment require another review?

The goal is not simply to restrict users.

It is to make the record accountable.

6. Evaluate investigations as a continuation of the case

Many systems perform reasonably well at initial incident reporting but become awkward once the case requires investigation.

Ask the vendor to show what happens when patrol finishes its part and an investigator takes over.

The investigator should not have to rebuild the case from a PDF report.

Evaluate:

• Assignment
• Multiple investigators
• Investigative supplements
• People and associations
• Evidence
• Documents
• Warrants
• Tasks/follow-up
• Notes
• Case status
• Supervisory visibility
• Complete case history

Ask:

Can an investigator begin with everything patrol already knows and add to that history?

That’s a much more useful question than simply asking whether the system has an “Investigations module.”

7. Test search with real questions

A records system is only useful if users can find the record later.

Don't let the vendor demonstrate search using a perfectly known incident number.

Give them messier questions.

For example:

Show me everything involving John Smith.

Then:

Show me reports involving a white Ford pickup with a partial plate.

Or:

Find incidents at this address during the last two years.

Or:

Show me records involving this phone number.

Or:

Find reports involving this person and this vehicle.

Evaluate searches across:

• Names and aliases
• DOB
• Driver's license
• Addresses
• Phone numbers
• License plates
• VIN
• Property
• Incident numbers
• Offense
• Date ranges
• Locations

Search is one of the capabilities users will depend on for years after the original report was written.

8. Treat Texas NIBRS reporting as a core requirement

For a Texas agency, NIBRS is not an optional add-on.

Texas DPS states that, effective September 1, 2023, Texas criminal-justice agencies are required to implement a NIBRS-compliant RMS and submit NIBRS data monthly to the Texas DPS UCR Program.

So don't simply ask:

“Does your system support NIBRS?”

Ask the vendor to show you the process.

Ask to see

• How NIBRS-required data is collected during normal report entry
• How missing or invalid information is identified
• How records staff find reporting problems
• How errors are corrected
• How submissions are generated
• How rejected/error records are handled
• How corrections get back into the operational record
• Who supports the agency when reporting specifications change

Texas DPS currently accepts 2019 and 2023 NIBRS specification versions and maintains separate Texas-mandated specifications. Its Texas-specific reporting includes Sexual Assault, Drug Seizures, and Family Violence data. DPS also maintains Texas UCR offense-code guidance for agencies and RMS vendors.

That means “supports FBI NIBRS” is not, by itself, enough of an answer for a Texas RMS evaluation.

Ask the vendor about Texas specifically

• How many Texas agencies are currently submitting through your RMS?
• Which Texas specification version do you support?
• How do you maintain Texas-specific requirements?
• How quickly do you respond to DPS specification changes?
• How are Texas UCR offense-code changes handled?
• Who works with us during certification or recertification?
• What happens when our submission contains errors?

Texas DPS maintains a public list of vendors actively working with Texas agencies to submit NIBRS. To appear on that list, DPS says a vendor must be working with a Texas LEA through the certification process and actively submitting live data. DPS also makes clear that inclusion does not mean the vendor is CJIS compliant.

Vendors actively working with Texas agencies to submit NIBRS (Texas DPS)

Check the list as part of your due diligence—but don't make it your only test.

Changing RMS vendors can also trigger NIBRS recertification. DPS's current certification procedures specifically address agencies recertifying because of a vendor or vendor-product change.

For Texas-specific reporting, certification, errors, and vendor questions, read the Texas NIBRS Reporting Guide.

9. Evaluate security as a system, not a checkbox

“CJIS compliant” should not end the security conversation.

The FBI describes protection of criminal justice information as a shared responsibility, and Texas DPS maintains both FBI CJIS materials and Texas-specific requirements for agencies and contractors.

Ask the vendor to explain:

• Hosting environment
• Encryption in transit
• Encryption at rest
• Authentication
• Multi-factor authentication
• User provisioning/deprovisioning
• Role-based access
• Privileged/admin access
• Audit logging
• Security monitoring
• Backups
• Recovery
• Incident response
• Vulnerability/remediation processes
• Vendor personnel access to agency data
• Subcontractors/service providers
• Data retention and destruction

Ask for documentation

A serious vendor should be prepared to discuss its security architecture and provide appropriate documentation during procurement.

Also determine which security responsibilities belong to the vendor versus your agency.

CJIS security is not something an agency can completely outsource by buying software.

10. Examine permissions at the level your agency actually needs

“Role-based permissions” can mean almost anything.

Give the vendor actual scenarios:

Can patrol officers see an active internal investigation?

Can a dispatcher see information necessary for the call without receiving unnecessary access to investigative records?

Can an investigator access restricted case material?

Can records personnel correct data without silently changing an approved officer report?

Can an administrator manage users without having unrestricted operational access?

Can we restrict a particularly sensitive case?

Then ask whether those decisions are audited.

Permissions should follow the job without making normal work impossible.

11. Make the vendor demonstrate audit history

Pick a record and change something.

Then ask:

Show me who changed it.

Ask whether you can determine:

• Who created the record
• Who submitted it
• Who reviewed it
• Who rejected it
• Who approved it
• What changed
• When it changed
• Who changed it
• What workflow actions occurred

For sensitive public-safety records, the history of the record can be almost as important as its current state.

12. Understand CAD and RMS together

If you use CAD, don't evaluate RMS as though the call for service never happened.

Ask:

What information carries from CAD into RMS?

Ideally, the RMS should be able to use relevant information already captured during the response, such as:

• Call number
• Date/time
• Location
• Units
• People
• Vehicles
• Disposition
• Call notes/history where appropriate

Then determine what remains authoritative in CAD versus RMS.

The objective isn't to combine two different operational systems into one screen.

It is to prevent the story from unnecessarily starting over when the work crosses from dispatch into records.

13. Evaluate mobile citations and field work

If citations are part of the deployment, demonstrate one from beginning to end.

Have the vendor show:

Driver → vehicle → violation → location → signature → issuance → RMS/records → court handoff, if applicable

Look for opportunities to avoid retyping information that has already been captured.

Also evaluate:

• Driver's-license workflows
• Vehicle lookup
• Offense selection
• Location
• Officer information
• Printing
• Signatures
• Amendments/voids
• Court export/handoff
• Reporting

The best time to evaluate this is with an officer who actually writes citations.

14. Treat data conversion as part of the RMS purchase

Your historical records do not stop mattering because you changed vendors.

Before signing, determine exactly what the new vendor proposes to convert.

Create an inventory of:

• Incidents
• People
• Organizations
• Vehicles
• Arrests
• Citations
• Warrants
• Property
• Evidence
• Investigations
• Supplements
• Attachments
• Scanned documents
• Code tables
• Personnel
• Historical statuses/dispositions
• Relationships between records

Ask the new vendor

• Have you converted data from our existing system before?
• What source format do you need?
• Who extracts the data?
• What doesn't get converted?
• Are attachments included?
• Are relationships preserved?
• How will legacy records be identified?
• How will converted data be validated?
• Will we receive exception reports?
• Who signs off on the conversion?
• What happens if problems are found after go-live?

A conversion should not be judged merely by whether the rows imported.

You need to know whether the historical record remains understandable and usable.

For a fuller treatment of exports, mapping, attachments, validation, and go-live or backfill, read the data conversion guide.

15. Require a conversion validation plan

Before go-live, agree on how the conversion will be tested.

At minimum, consider:

• Record counts — compare major source and destination totals
• Date ranges — verify old and recent records
• Sample records — select known complicated cases, not only easy ones
• Relationships — confirm people, vehicles, offenses, property, evidence, supplements, and attachments remain connected
• Attachments — open them
• Search — find converted records through normal user searches
• Exceptions — document records that could not be converted cleanly
• Agency acceptance — validate converted data before the new system becomes authoritative

16. Ask about data ownership before signing

Ask directly:

Who owns our data?

Then ask:

If we leave five years from now, how do we get it back?

Understand:

• Export options
• Formats
• Attachments
• Database access
• Costs
• Timelines
• Retention after termination
• Deletion/destruction procedures

An RMS can contain decades of institutional history.

Your ability to retrieve that history should not depend entirely on the goodwill of your current vendor.

17. Evaluate implementation, not just software

A good product can still fail through a bad implementation.

Ask who will be responsible for:

• Project management
• Configuration
• Data conversion
• User setup
• Workflow configuration
• Training
• Testing
• Cutover
• Go-live support
• Post-launch follow-up

Then ask:

Who will we actually work with?

Try to meet those people before signing.

Ask for an implementation plan

It should identify major stages such as:

Discovery → configuration → conversion → validation → training → go-live → stabilization

Ask what the agency will be responsible for at each stage.

18. Evaluate training with real workflows

Training should not just explain where buttons are.

Ask how the vendor trains:

• Officers
• Dispatchers
• Investigators
• Supervisors
• Records personnel
• Administrators

Each role has different work.

Training should use realistic scenarios so users understand not only how to click something, but how a record moves through the system.

Also ask:

• Is training remote or onsite?
• Is refresher training available?
• Are training materials provided?
• What happens when you hire someone six months later?
• Is there a training/test environment?

19. Find out what support looks like after go-live

This is difficult to judge during procurement, so ask references.

Don't ask only:

“Are you happy with the vendor?”

Ask:

• When you have a real operational problem, how quickly can you reach someone who understands it?
• Do you repeatedly explain your agency to different support representatives?
• Does the person answering understand the product?
• How are urgent problems escalated?
• Does the vendor communicate during outages?
• What happens when you need configuration changed?
• Has the vendor been responsive to reasonable product feedback?

References often reveal more about the long-term relationship than another demo will.

20. Understand how product changes are handled

Public-safety requirements change.

Texas reporting changes. Security requirements change. Agency workflows change.

Ask:

• How frequently is the product updated?
• How are changes communicated?
• Are updates included?
• Can updates break agency-specific configuration?
• How are regulatory changes prioritized?
• How does customer feedback reach the product team?
• How are emergency fixes handled?

You're not buying only the version demonstrated today.

You're choosing the organization responsible for maintaining it tomorrow.

21. Evaluate reliability and recovery

Ask what happens when something goes wrong.

Discuss:

• Service availability
• Planned maintenance
• Backups
• Backup frequency
• Recovery objectives
• Geographic/redundancy strategy
• Disaster recovery
• Status communication
• Outage procedures
• Data restoration testing

Then ask a practical question:

What does our agency do if the system is unavailable at 2:00 a.m.?

The answer should include both technology and operations.

22. Ask about integrations carefully

“Integrates with everything” is not a useful answer.

Make a list of the systems your agency actually needs.

For each one, classify it:

Then require the vendor to identify each integration as:

Available today / configuration required / custom development required / planned / unsupported

If something is important enough to influence the purchase decision, put its scope in writing.

23. Understand the real price

Compare total cost, not the headline license price.

Ask about:

• Annual software licensing
• Per-user/per-officer charges
• Implementation
• Data conversion
• Training
• Travel
• Integrations
• Interfaces
• Hosting
• Storage
• Support
• Upgrades
• Additional modules
• Hardware
• Payment processing where applicable
• Future expansion

Then model the cost over several years.

An inexpensive implementation with rapidly increasing recurring costs may be more expensive than a higher initial proposal.

Conversely, don't choose a system simply because it is cheapest.

Replacing an RMS is expensive in time, disruption, training, and institutional attention even when the software itself is inexpensive.

24. Check references that resemble your agency

A 1,500-officer department and a 12-officer department may have very different experiences with the same product.

Ask for references similar to your agency in:

• Size
• State
• Operational structure
• Products deployed
• Reporting requirements
• Legacy system
• Implementation complexity

For Texas agencies, references from Texas agencies actually using the product are particularly valuable because they can speak to DPS reporting and state-specific workflows.

25. Make vendors demonstrate your scenarios

Before the final demonstration, give every finalist the same scenarios.

For example:

Scenario A — Patrol report

Create an incident from a call for service, add two people and a vehicle, attach evidence, submit it, reject it during review, correct it, and approve it.

Scenario B — Investigation

Assign the approved incident to a detective, add investigative activity, associate a warrant, and show the complete case history.

Scenario C — Search

Find everything involving one person, then find incidents involving a partial plate and a particular address.

Scenario D — NIBRS

Show how a records user identifies missing NIBRS data, corrects it, validates the record, and prepares it for submission.

Scenario E — Audit

Change important information on an existing record and show us exactly how the change appears in audit history.

Scenario F — Supervisor

Show everything currently waiting for this supervisor and identify which work has been returned, corrected, or is overdue.

This makes comparisons dramatically more useful.

A practical RMS evaluation scorecard

Don't score every feature equally.

A useful starting point is:

Change the weights to fit your operation.

More importantly, establish a few pass/fail requirements.

A vendor that fails a mandatory security, reporting, conversion, or operational requirement should not win simply because it accumulated points elsewhere.

30 questions to bring to every RMS demonstration

Print this section and keep it open during vendor demos.

1. Show us an incident from creation through final approval.
2. Show us a rejected report being corrected and resubmitted.
3. What information carries from CAD into RMS?
4. Show us a patrol case being assigned to an investigator.
5. Can multiple investigators work a case?
6. Show us everything associated with one person.
7. Show us a search using incomplete information.
8. How are duplicate people detected?
9. How are historical changes to master records handled?
10. Show us what a patrol officer sees when logging in.
11. Show us what a supervisor sees.
12. Show us what records personnel see.
13. How do users know what work still needs attention?
14. Show us the NIBRS workflow.
15. How are NIBRS errors identified and corrected?
16. How do you support Texas-specific UCR requirements?
17. Which Texas agencies currently submit NIBRS using your system?
18. What happens if Texas DPS changes its specifications?
19. Show us the audit history for a changed record.
20. How granular are permissions?
21. Where is agency data hosted?
22. How are authentication and MFA handled?
23. What is your incident-response process?
24. What exactly will you convert from our existing RMS?
25. How will we validate the conversion?
26. How do we retrieve our data if we leave?
27. Who will implement and train our agency?
28. Who handles our support after go-live?
29. Which requested integrations exist today?
30. What will our total cost be over five years?

Watch for these warning signs

An evaluation deserves additional scrutiny when:

• The demo avoids real workflows — lots of dashboards, few complete scenarios.
• The answer to every integration question is “yes.” Ask to see it.
• NIBRS is treated as an export button. Reporting quality begins with the data captured during the operational workflow.
• Historical conversion is vague. “Don’t worry, we’ll import it” isn’t a conversion plan.
• Security is reduced to “we’re CJIS compliant.” Ask for specifics and documentation.
• The product requires duplicate entry between its own components.
• Nobody can show you an audit trail.
• The vendor won’t let you talk to comparable customers.
• Implementation ends at training day.
• Roadmap features are presented as current functionality. Roadmaps are useful — they should not be confused with what you’re purchasing today.

The final question

After you've compared the features, reporting, security, implementation, conversion, and price, ask your evaluation team one more question:

Does this system fit the way our agency actually works?

Your RMS will sit underneath years of reports, investigations, people, property, evidence, supervisory decisions, and required reporting.

The software should create a dependable record without becoming an obstacle to the work that creates it.

Choose accordingly.

Evaluating an RMS for a Texas agency?

Thin Line Software builds records management and public-safety software around the way the operation actually moves—from patrol and supervisory review through investigations, records, and reporting.

Thin Line Software is currently listed by the Texas Department of Public Safety among vendors actively working with Texas agencies to submit NIBRS data. DPS notes that this listing reflects NIBRS reporting/certification activity and does not itself establish CJIS compliance.

Texas DPS NIBRS vendor listing