The word “configurable” sounds harmless. It sounds flexible. It sounds like the vendor has built software that can adapt to the agency without major cost or risk.
Inside mission-critical software procurement, “configurable” is one of the most expensive words in the contract.
The problem is that vendors and agencies often hear two different things.
The agency hears: “My admin team can adjust this after go-live without needing the vendor.”
The vendor may mean: “Our implementation team can make this work during deployment, assuming the required data exists, the workflow is supported, the integration behaves as expected, and the effort is inside scope.”
Those are not the same statement.
In CAD, RMS, JMS, evidence, NG911, station alerting, digital evidence, and mobile platforms, the difference matters. These are not ordinary business applications. They sit inside live operational workflows. They affect call handling, dispatch, field safety, case documentation, evidence integrity, reporting compliance, and long-term agency control. The word “configurable” carries enormous weight in those environments, and most agencies never pause to decompose it before signing.
The thesis of this Insight is straightforward.
“Configurable” is not a capability until the agency knows who can configure it, where it is configured, how it is tested, what it costs, whether it survives upgrades, and whether the configuration can be changed without calling the vendor.
What “Configurable” Actually Means Inside A Vendor
When a vendor says “configurable,” they may be talking about at least seven different things. Most agencies hear only the first one. The other six are where the cost lives.
1. True admin settings
This is the cleanest version. The agency has an administrator screen. The setting is exposed. The agency can change it without code, without vendor support, and without a release cycle.
Examples include agency name, ORI, default juvenile age, dispatch priority codes, disposition codes, role permissions, notification thresholds, unit status values, and report routing rules.
This is what agencies usually think they are buying.
The Bureau of Justice Assistance and LEITSC RMS functional standards describe this kind of configuration directly. RMS systems should allow system administrators to maintain tables, role security, parameters, defaults, geofile, data dictionary, and archive and purge rules. The standards specify that configuration parameters such as agency name, ORI, juvenile default age, geography coordinates, name match rules, and alert and notification conditions should be changeable by the system administrator.
That is real configuration.
2. Exposed configuration UI, but only for limited behavior
This is still legitimate, but narrower. The agency may be able to configure tabs, filters, columns, colors, views, map layers, alerts, or queues, but not the core workflow logic.
Motorola's CommandCentral Aware documentation provides a fair example of this category. The event monitor can be customized with filters, tabs, column visibility, and ordering. Automation rules can trigger actions such as highlighting events or playing nearby cameras.
That is useful. It is not the same as saying the entire operational workflow is configurable.
3. Workflow builder or rules engine
This is more advanced. The product has a rules engine or workflow tool that allows agency administrators to model routing, approvals, alerts, queues, escalations, or task assignments.
This can be extremely valuable if it is truly user-administered. Agencies need to know whether the builder is actually available to them, whether it requires certified vendor training, whether changes can be tested in a sandbox, and whether the vendor still has to publish or approve the change.
4. Form designer
This is common in RMS, JMS, fire records, inspection, and evidence systems. A vendor may say forms are configurable, meaning the agency can add fields, rearrange sections, require certain entries, or create supplemental forms.
The catch is whether those form changes propagate through the rest of the system.
A form field is not just a field. It may affect search, reporting, NIBRS and IBR export, prosecutor packages, evidence linkage, audit logs, mobile display, role security, data migration, retention, and public records redaction.
A form editor that only changes the screen is not the same as a schema-aware form designer that understands the downstream data model. The first one looks the same in the demo. It costs the agency every time the data model needs to evolve afterward.
5. Reporting configuration
This means the vendor has a reporting tool, a dashboard tool, an ad hoc query builder, or a third-party BI layer.
Useful, but dangerous if not controlled. The BJA and LEITSC standards warn that stand-alone ad hoc reporting tools can create security trade-offs if they bypass RMS security controls for juvenile, sealed, or redacted records.
In public safety, reporting is not just analytics. It is compliance, discovery, public records production, command accountability, and sometimes litigation.
6. Interface mapping or API configuration
This is when the vendor says, “Yes, we can configure the interface.”
Sometimes that means a real mapping layer exists. Sometimes it means professional services will write transformation logic between two systems.
The New York State Police and Niche RMS materials are a good example of what a serious answer looks like. Niche described CAD integration as a standard feature, but then explained that the NYSP-specific Hexagon CAD format would be configured, that local business requirements would drive the questionnaire, that customers use different subsets of data elements and different code mappings, and that source data quality determines whether automatic entity resolution can work reliably.
That is the level of specificity agencies should demand.
7. “Configurable through professional services”
This is the most dangerous version.
It usually means: “The product does not do that out of the box, but we can make it do that if you pay us.”
That is not configuration in the way most agencies understand it. That is custom development, custom integration, or custom implementation work with softer language on the invoice.
If the agency cannot see the screen, name the role that can change it, test the change in a sandbox, and repeat the change after go-live without vendor intervention, then the agency should not accept the word “configurable” at face value.
What “Yes, With Configuration” Really Means In An RFP Response
In public safety software RFPs, vendors rarely say no.
They say: Yes. Yes, with configuration. Yes, with workflow. Yes, with integration. Yes, through API. Yes, planned. Yes, with professional services. Yes, with third-party solution. Yes, future roadmap.
The problem is that many agencies score those answers too generously.
A meaningful “Yes” means the function exists today, is in the base product, is demonstrable in a live or sandbox environment, is operating at reference sites, is included in pricing, is supported by standard documentation, and does not require custom code.
A meaningful “Yes, with configuration” means the function exists today, but agency-specific values, rules, forms, permissions, code tables, or workflows must be configured using standard tools already included in the product and already scoped in the implementation.
A meaningless “Yes, with configuration” means: we believe this can be made to work later.
That is not enough.
The City of San Gabriel's RMS RFP response structure is a useful model because it forces vendors to separate base product from modification and custom enhancement. It defines “I” as included in the base product and available for demonstration now, “M” as modification required with itemized costs, and “C” as custom enhancement that must be added to meet the requirement with costs itemized.
That is exactly the distinction most RFPs fail to enforce.
How a “Yes, with configuration” becomes a six-figure change order
A mid-sized law enforcement agency includes this requirement in its RMS RFP.
“The RMS shall automatically route reports based on offense type, reporting district, arrest status, juvenile involvement, and supervisory chain of command. The routing shall trigger required review steps, notify the assigned supervisor, prevent submission when required fields are missing, and generate an audit trail.”
The vendor marks: “Yes, configurable.”
The agency hears: “Great. We can set up routing rules.”
What the vendor actually meant was different. The base RMS has a generic approval queue. Routing by offense type exists in the standard product. Routing by reporting district requires code-table mapping. Juvenile handling requires a separate security rule that has to be configured. Supervisory chain of command is not natively connected to the agency's HR data. Missing-field validation requires form-level rules. Notifications require separate template configuration. The audit trail requires a report to be built. Mobile submission behavior must be tested separately because the rules engine handles mobile differently. The agency's desired escalation path is not part of the standard workflow at all.
During deployment, that single requirement becomes a discovery item. Then a scope question. Then a professional services estimate. Then a change order.
The agency thought it bought configuration. What it bought was a placeholder.
That is how a requirement marked “Yes, with configuration” can become a six-figure change order. It does not happen because the vendor lied. It happens because the agency did not require the vendor to decompose what “configuration” meant for that specific requirement before signing the contract.
“Yes, with configuration” should never receive full credit until the vendor proves where the configuration lives, who performs it, how many hours are included, and what happens when the agency changes its mind after go-live.
What Truly Configurable Software Looks Like From The Engineering Side
From an engineering perspective, truly configurable software is not a product with a few settings screens.
Truly configurable software is built around a configuration model. That means the application understands the agency's configuration as structured data, not as scattered one-off scripts or hardcoded exceptions.
Schema-aware configuration. When the agency adds or modifies a field, the system understands what that field is, where it appears, who can see it, how it is validated, whether it is searchable, whether it is reportable, whether it is exportable, and whether it is subject to retention or redaction.
Workflow engines that do not require code. An administrator can create or modify routing rules, approvals, queues, alerts, escalations, and task triggers without opening a development ticket with the vendor.
Form designers that propagate changes. If a field is added to a report form, the system can carry that field into search, reporting, export, audit, mobile, and role-security logic where appropriate.
Configuration versioning. Changes can be tracked, tested, promoted, rolled back, and audited. This matters in public safety because a bad configuration change can disrupt live operations.
Role-based configuration authority. A records administrator, CAD administrator, fire administrator, and system administrator may need different permissions. Configuration authority must be controlled, audited, and matched to operational responsibility.
Sandbox-to-production promotion. A real system allows configuration to be tested in a non-production environment before being deployed to live operations.
Upgrade-safe configuration. The configuration survives vendor upgrades without being rewritten. Configurations should be stored separately from code and regression-tested as part of the release cycle.
Open, documented APIs tied to the configuration model. The API should not just expose raw data. It should respect agency configuration, permissions, audit rules, and data standards.
A lot of legacy public safety platforms were not originally built this way.
They were built as hardcoded products that evolved through customer-by-customer customization. Over time, vendors exposed some tables, some settings, some XML mappings, some reports, and some admin screens. Then sales began calling the whole product “configurable.”
That is where agencies get trapped.
After go-live, the agency wants to make a reasonable change. Add a report field. Change approval routing. Add a validation rule. Adjust a call type. Modify a fire recommendation rule. Add an evidence disposition. Change a jail classification workflow. Adjust an officer safety alert. Change a prosecutor export. Add a new agency in a multi-jurisdiction environment.
If the agency can do that itself, the system is configurable.
If the vendor has to scope it, estimate it, schedule it, code it, QA it, and invoice it, the agency bought a services dependency.
The test is not whether the system could be configured during implementation. The test is whether the agency can safely change it after implementation without starting a new vendor negotiation.
How “We Will Configure It During Deployment” Becomes A Change Order
This trap follows a predictable path.
Step one: pre-sales language. The vendor says, “Yes, that is configurable.” The agency does not ask what kind of configuration.
Step two: RFP response ambiguity. The vendor marks the requirement “Yes” or “Yes, with configuration.” The agency gives it full or near-full credit.
Step three: contract scope is too general. The SOW says the vendor will “configure workflows,” “configure forms,” “configure interfaces,” or “configure reports,” but does not identify the exact workflows, forms, rules, interfaces, reports, data mappings, acceptance criteria, assumptions, or hours.
Step four: implementation discovery. During design, the agency explains the actual business process. The vendor realizes the workflow is more complex than assumed.
Step five: scope dispute. The vendor says, “That is not standard configuration.” The agency says, “You marked yes.” The vendor says, “We can do it, but it was not in the contracted scope.”
Step six: change order. The agency now has three bad options. Pay the change order. Accept a workaround. Delay go-live.
This is how “configurable” becomes expensive. Not through bad faith. Through ambiguity that the agency did not force the vendor to resolve before signing.
What the agency should demand before contract
The agency should require the vendor to identify every “Yes, with configuration” requirement and classify it as one of the following. User-admin configurable. Vendor-admin configurable. Professional services configuration. Report configuration. Form configuration. Workflow or rules configuration. Interface mapping. API-based integration. Custom enhancement. Roadmap item. Third-party dependency. Not available.
Then for each one, the agency should require the configuration owner, the configuration tool name, estimated hours, included or extra cost, assumptions, required data, required agency decisions, the testing method, acceptance criteria, the upgrade impact, and the post-go-live change process.
“We will configure it” is not a scope statement. It is the beginning of a scope statement.
Acquired Products, Suites, And Where “Configurable Integration” Breaks
The public safety software market has been consolidating for years.
Motorola Solutions acquired Spillman to expand its command center capabilities, describing the acquisition as part of a strategy to provide a full suite from call processing to CAD, RMS, LMR, and LTE dispatching. CentralSquare was formed from the merger of Superion, TriTech, Zuercher, and Aptean's public sector business, and described itself as holding the number-one market position in public safety software. Tyler acquired New World Systems in a $670 million transaction to strengthen its public safety position and create an end-to-end criminal justice solution with Tyler's Odyssey courts platform. Hexagon acquired Intergraph, which operated in security, government, infrastructure, geospatial intelligence, and critical infrastructure software.
None of this is inherently bad. Some acquisitions bring capital, scale, support, and better product investment.
Architecturally, acquired products create seams. Those seams are where “configurable” breaks.
Different data models. The CAD product may define incident, unit, location, person, vehicle, and agency differently than the RMS, evidence, jail, or analytics product. The seam is the translation layer between them.
Different identity models. One product may use local users. Another uses SSO. Another uses role groups. Another uses inherited permissions. “Integrated suite” does not always mean unified identity.
Different audit models. Public safety systems need strong audit trails. If CAD, RMS, evidence, and jail modules audit differently, the agency may have gaps it cannot see until an audit or a discovery request exposes them.
Different release cycles. One acquired product may release quarterly. Another may be legacy and release annually. Another may be cloud-only. Another may still support on-prem. “Configurable” becomes fragile when each product evolves on its own schedule.
Different UI frameworks. Users may be told they are buying a suite, but they experience multiple products stitched together with links and shared branding.
Different integration layers. The vendor may rely on an internal API, a message bus, middleware, batch files, a database view, or a custom connector. The agency needs to know which one and who owns the connection.
Different support teams. Even inside one vendor, support may still route to product-specific teams inherited from the original acquisitions.
The core product may work well. The acquired product may work well. The problem is the handoff.
A CAD incident becomes an RMS report. A field report becomes a case. A case becomes evidence. Evidence becomes discovery. A jail booking becomes a court record. A fire response becomes state reporting. A CAD event becomes analytics.
The vendor says: “The suite is configurable.”
The engineer asks: which product owns the master record, which API moves it, which code table translates it, which audit log records it, and which support team fixes it when it fails?
That is the conversation agencies need to have before award.
The RegJIN project is a public example of how complex multi-agency RMS environments can become. RegJIN was designed as a regional platform involving more than 40 jurisdictions across two states, serving 5,000 to 6,000 users and generating roughly 50,000 electronic police reports per month. Later reporting indicated that more than 50 percent of non-Portland Police Bureau users had left the system, with complaints about inefficiency, report-writing burden, and difficulty transmitting crime data to state and federal officials.
That is not just a bad-software story. It is a warning about complexity, workflow fit, reporting, integrations, governance, and end-user reality. The architectural seams in a regional multi-agency deployment compound every weak “configurable” answer in the original RFP. Whatever the vendor could not configure cleanly at one agency becomes whatever the vendor cannot configure cleanly at forty agencies.
Suites do not fail at the brochure level. They fail at the seams.
The Truth About “Configurable Through Our API”
“Configurable through our API” is one of the newer escape hatches in vendor language. Sometimes it is real. Sometimes it is custom development with a modern label.
An API is not automatically a solution. It is an interface. It gives someone a way to move data or trigger behavior. Someone still has to design, build, test, secure, monitor, and maintain whatever uses that API.
In public safety, API-based configuration is real when the API is published and documented, the vendor supports it commercially, authentication and authorization are clear, it respects CJIS and other security rules, rate limits are known, error handling is documented, versioning is managed, sandbox access is available, webhooks and events are supported where needed, the integration survives upgrades, and the agency has either internal engineering capacity or a funded support model behind it.
It is not real when the vendor says “we have an API” but will not publish documentation pre-contract, when only the vendor's professional services team can actually use it, when the API does not expose the workflow the agency needs, when the API exposes data but not configuration, when every change requires custom code, when upgrades break the integration, when monitoring is not included, or when no one owns support for the integration after go-live.
The National 911 Program's CAD interoperability report is blunt about the market reality. The report captured solution-provider feedback that CAD vendors do not want to be easily interchanged, that competing CAD vendors do not always cooperate, and that vendors often do not publish APIs or have a commercial interest in exchanging data with competitors.
That matters because agencies are often told API access solves the problem. It may not.
The NYSP and Niche example shows the honest version. APIs and interface flexibility can be real, but successful automation depends on local business requirements, code mappings, data quality, fielded elements, and source-system formats. If source data arrives as a compound address label instead of fielded address elements, reliable automatic linking becomes difficult or impossible. The API is the door. The work the agency wants done lives on the other side of the door, and somebody has to do that work.
An API is not configurability. An API is a door. The agency still needs to know who is building the hallway, who maintains it, who secures it, and who answers the phone when it breaks at 0200.
The Practitioner's Checklist: Better Questions Before The Contract
Agencies can avoid most of these traps by asking better questions during the RFP and pre-contract phase. These are the questions Sentinel coaches agencies to put on the table.
Question 1: Show me the configuration UI
Not a slide. Not a statement. Not a promise. Show the actual screen where my administrator would make the change. Then ask what role is required, whether my agency can have that role, whether training is included, whether the change is audited, whether it can be tested before production, and whether it can be rolled back.
Question 2: For every “Yes, with configuration,” classify the configuration type
The agency should not accept a single phrase. Require vendors to identify whether the requirement is native or base product, user-admin configurable, vendor-configurable, workflow or rules engine, form designer, report builder, interface mapping, API integration, professional services, custom enhancement, roadmap, or third-party dependency.
Question 3: What percentage of requirements are native versus configurable?
If a vendor marks 90 percent “Yes,” that is not enough. Ask how many are native. How many require configuration. How many require vendor staff. How many require custom code. How many require third-party tools. How many are not demonstrable today.
Question 4: Walk through this change as if we are already live
Give the vendor a realistic future-state scenario. “Six months after go-live, we add a new juvenile review workflow. Show us how our admin would add the fields, modify routing, update validation, test it, publish it, report on it, and confirm audit logging.” If the answer becomes, “We would need to scope that,” you have your answer.
Question 5: What requires a release cycle?
Ask directly. What changes can be made immediately by agency admins. What changes require vendor configuration. What changes require professional services. What changes require product development. What changes require a version release. What changes are prohibited in SaaS deployments. What changes affect supportability.
Question 6: Does configuration survive upgrades?
A system is not truly configurable if every upgrade threatens to break the agency's configuration. Ask whether configurations are stored separately from code, whether they are regression-tested, whether they are included in release testing, whether the vendor certifies agency configuration after upgrades, and what happens if a release changes behavior.
Question 7: What is included in the implementation estimate?
For each configurable requirement, require hours, owner, assumptions, deliverable, acceptance criteria, testing responsibility, agency inputs, excluded work, and change-order triggers.
Question 8: Can we talk to a customer who made this exact change?
Not a similar change. The exact change. If the vendor says it is configurable, there should be another agency that has actually configured it.
Question 9: Can we access a sandbox before award?
For complex procurements, the agency should push hard for scripted sandbox validation or at least a structured demonstration environment. The demo should not be a sales tour. It should be an engineering test against the agency's actual workflows.
Question 10: Who owns configuration after go-live?
This is the question most agencies forget. Agency admin? Vendor support? Vendor professional services? Product team? Third-party integrator? Managed services provider? No one?
The agency should not ask, “Is it configurable?” The agency should ask, “Show me exactly how it changes after go-live, who changes it, what it costs, and what breaks if we do it wrong.”
What Sentinel Does When Every Vendor Says “Configurable”
Sentinel's role is not to argue with vendors for the sake of arguing. It is to translate vendor language into operational, technical, contractual, and financial reality.
Several specific practices anchor this work.
Sentinel decomposes the word “configurable.” We do not let “configurable” sit in the requirements matrix as a vague answer. We classify it. For each requirement, we ask whether it is native, admin-configurable, vendor-configurable, workflow, reporting, integration, API, professional services, custom development, future roadmap, or excluded. That becomes a risk view for the agency before contract, not after go-live.
Sentinel reads the matrix the way engineering reads it. Sales teams write in outcomes. Engineering teams think in constraints. Sentinel looks for the constraints: data model, schema, API coverage, interface ownership, code-table mapping, workflow engine limits, audit behavior, security model, testing environment, release management, upgrade survivability, vendor staffing assumptions, and change-order exposure. That is the difference between a procurement file that holds together and a procurement file that collapses six months after award.
Sentinel forecasts change-order risk before award. If 40 percent of the agency's critical requirements are marked “Yes, with configuration,” that is not just a scoring note. It is a budget risk, a schedule risk, an acceptance risk, and a governance risk. Sentinel identifies the gray-zone requirements that are most likely to become change orders, then forces clarification before contract rather than after.
Sentinel demands proof. For critical configurable claims, we push for scripted demonstrations, sandbox validation, configuration screenshots, admin-role walkthroughs, sample configuration documentation, reference checks with agencies who have actually made the same change, confirmation of included hours, SOW language tied to those hours, acceptance criteria, and a post-go-live support model.
This is what differentiates Sentinel from firms that read RFP responses as a scoring exercise. We read them as engineering documents. We have written enough of them from the vendor side to know what is being left out.
Sentinel reads the requirements matrix the way the vendor's engineering team reads it, not the way the vendor's sales team writes it.
The Cost Of An Undecomposed Word
The public safety software market has trained agencies to accept “configurable” as a positive answer. It should not be accepted that easily.
Configurable can mean agency control. It can also mean vendor dependency. It can mean flexibility. It can also mean unfinished scope. It can mean modern architecture. It can also mean legacy code with a few exposed tables. It can mean low-risk adaptability. It can also mean the first change order of the project.
The difference has to be forced into the open before award.
The expensive problems in mission-critical software are rarely the ones the vendor marks “No.” The expensive problems are the ones marked “Yes” that nobody decomposed.
Agencies that treat “configurable” as a binary answer end up paying the difference in change orders, scope disputes, deployment delays, and post-go-live frustration. Agencies that treat “configurable” as a category of seven distinct things produce procurement files that hold together, contracts that scope honestly, and deployments that finish on something close to the original budget.
Sentinel governs the procurement. We never sell the platforms. Independent. Practitioner-led. Vendor-neutral. Built for the engineering reality of the systems agencies actually have to operate, not the marketing language vendors use to sell them.
When a vendor says the system is configurable, the agency should not hear reassurance. It should hear an engineering question: configurable by whom, using what tool, at what cost, under what scope, with what testing, and with what risk after go-live?
That is the conversation that protects the agency. It is also the conversation most vendors would rather not have. The agencies that force it pay less. The agencies that skip it pay for years.