How to evaluate an integration platform: an RFP checklist for cities and counties
A practical checklist for writing or scoring an integration platform RFP: data handling, security, government connectors, operations, hosting, accessibility, AI and the exit plan.
Most integration RFPs are copied from a general IT template. They ask about uptime, connector counts and support hours, then miss the questions that matter most to a public agency: where resident data ends up, who can change a flow, and how you leave.
This checklist is meant to be pasted into a scope of work or used as a scoring sheet. Adjust it to your agency's rules.
Start with the problem, not the product
Before writing requirements, list the connections you actually need. For each one, write down:
- The two systems, and which one is the system of record.
- How often the data must move: as it happens, hourly or nightly.
- What kind of data it is: public, internal, personal, financial or criminal justice.
- Who owns it on each side, and who fixes it when it breaks.
Ten real connections tell vendors more than fifty pages of generic requirements. Put the list in the RFP as an appendix and ask each vendor to describe how it would build three of them.
Data handling
This is the section most templates skip, and the one your records manager and counsel will care about.
| Ask | A good answer looks like |
|---|---|
| Where are records stored during a run? | In memory only, or a clear list of every staging table, queue and log |
| What does run history keep? | Counts, timings and IDs, with no field values |
| How does a retry work? | It re-reads the record from the source, or explains exactly what is stored and for how long |
| What do backups of the platform contain? | Settings and history, not records |
| How long are logs kept, and who sets it? | The agency chooses, with a legal hold option |
Ask for a screenshot of the run history for a real run. It answers most of these questions at once.
Security and access
- Sign-in: single sign-on through your identity provider (SAML), and automatic removal of people through SCIM.
- Two-step sign-in: available, and something you can require for everyone.
- Roles: at least a read-only role, a builder role and an admin role.
- Network limits: can sign-in and API tokens be limited to your networks?
- Credentials: encrypted at rest and never shown again after saving.
- Audit: a log of who changed which flow, which you can export or send to your security tools.
Ask vendors to state plainly which certifications they hold today and which they are only preparing for. Both answers are fine. Vague ones are not.
Government connectors
Generic platforms list hundreds of connectors for commercial software. What matters is whether yours are covered.
- List your permitting, 311, records, GIS, ERP, utility billing and HR systems by name.
- Ask which connectors are pre-built, which are tested on a live account, and which are built from documentation only.
- Ask what happens for a system with no connector: OpenAPI import, a generic REST connector, files or a database.
- Ask about databases (SQL Server, Oracle, PostgreSQL) and SFTP, which still carry much of the work.
Building and changing flows
Who can do it?
If only a developer can change a flow, every new field becomes a ticket. Ask whether an analyst can build one, and ask for a live demonstration rather than a video.
Can you see the data first?
Ask whether a builder can preview real records at each step before turning a flow on, and whether that preview writes anything. It should not.
Can you test and promote?
Ask whether flows can be tested without sending anything, and whether there are separate test and production environments with a controlled promotion step.
Operations
- Failure alerts: by email or chat, linking to the failed run.
- Partial failure: one bad record should not stop the whole run.
- Replay: failed records can be run again after the cause is fixed.
- Data-health alerts: warnings when a run succeeds but reads nothing, or volume suddenly changes.
- Lineage: search a record ID and see every run it went through.
Hosting and network reach
Ask whether the platform can be hosted by the vendor, run on your servers, or both. Ask how it reaches systems inside your network: a VPN, open firewall ports, or an outbound-only agent. Ask whether self-hosting is the same software or a separate edition.
Accessibility
Ask for a current VPAT or Accessibility Conformance Report for the admin interface, its date, and who wrote it. Ask whether the flow designer can be used by keyboard. Staff who build flows are covered by your accessibility obligations too.
AI, if offered
- Is it off until an administrator turns it on?
- What does it see: settings and field names, or record contents?
- Can it turn a flow on by itself? It should not.
- Is every AI call logged?
The exit plan
Every contract ends. Ask how you get your flows out (a readable export format, without secrets), and what happens to logs and settings at the end of the term. A vendor that answers this easily is usually easy to work with.
Scoring tips
- Weight data handling and operations at least as heavily as connector counts.
- Score the demonstration on your three real connections, not a scripted demo.
- Ask references specifically about the last time something broke and how it was handled.
How SentraBridge answers
SentraBridge was designed around these questions: pass-through records, metadata-only run history, retention you set, SSO and SCIM, hosted or self-hosted, and an honest list of which connectors are verified. The comparison page and security page cover the details, and the FAQ answers the short ones.