RFI_SF_Citywide_Integration_Layer_8.11.2026.pdf

Sourcing Event ID: 0000011996 1 of 20 August 10, 2026

REQUEST FOR INFORMATION (RFI)

Citywide Integration Layer

ISSUED BY: City and County of San Francisco, City Administrator's Office

ISSUE DATE: Monday, August 10th, 2026

PRE-PROPOSAL CONFERENCE: Wednesday, August 19th, 1-1:45pm PT Virtual via Microsoft Teams: Register here.

QUESTIONS DUE (via email): Monday, August 24th, 5pm PT

RESPONSES DUE (via email): Friday, September 18th, 5pm PT

SHOWCASE INVITATIONS SENT (if applicable)

Week of October 12, 2026

SOLUTION SHOWCASE

PRESENTATIONS (if applicable)

Week of October 19, 2026

SUBMIT TO: Amanda Wentworth Contracts & Procurement Manager Office of the City Administrator Amanda.Wentworth@sfgov.org

1. Purpose

The City and County of San Francisco ("City") is seeking information from interested parties on technology solutions that can serve as a shared integration infrastructure layer across City departments. The City's goal is to understand the current vendor landscape for enterprise integration, gather perspectives on implementation approaches, and inform a decision on whether to procure a commercial solution, build one in-house, or pursue a hybrid approach.

The City Administrator's Office is issuing this RFI to explore a common approach to system integration across departments. Today, departments use a variety of custom interfaces and integration methods to exchange data between systems. Many of these integrations are developed and maintained independently, resulting in duplicated effort and inconsistent approaches across the City.

For purposes of this RFI, "citywide integration layer" refers to the shared operational infrastructure that enables systems to securely exchange data, events, and business transactions across departments. The City is seeking technologies that support integration patterns such as APIs, event-driven messaging, workflow orchestration, file and batch integration, and data transformation under a common governance, security, and monitoring framework.

This is distinct from analytics or data warehousing pipelines whose primary purpose is reporting and analytics.

This RFI is not a solicitation and does not commit the City to any procurement. Its purpose is solely for information gathering. A firm or organization's response to this RFI, or lack thereof, will have no impact on the evaluation of responses to any subsequent Request for Proposals or other solicitation. The City welcomes submissions addressing any portion of the capabilities described herein, whether comprehensive or targeted, and welcomes joint vendor partnerships that combine complementary capabilities.

2. Background

The City's Data Architecture and Integration Challenge The City's data architecture has a few components:

https://events.gcc.teams.microsoft.com/event/789bcd65-0db5-416c-98a4-f7311f7599a0@22d5c2cf-ce3e-443d-9a7f-dfcc0231f73f?source=copyLinkLegacyShareLinkDialog mailto:Amanda.Wentworth@sfgov.org

Sourcing Event ID: 0000011996 2 of 20 August 10, 2026

• Systems of record are the applications where the City's data originates and where business transactions happen, e.g., case management platforms, electronic health records, benefits systems, financial systems, permitting tools, property records, and public safety applications

• The integration layer (focus of this RFI) is how data moves between systems. The City does not currently have a shared enterprise integration platform or standard approach to integration. Existing integrations span hundreds of SQL databases and enterprise applications and use a range of methods, including point-to-point connections, file transfers, batch jobs, APIs, and direct database connections. These integrations have been implemented over time using different technologies and standards, making them difficult to manage consistently across the City.

• The Unified Data Platform (Snowflake) is the City's governed foundation for enterprise reporting, analytics, and authorized data sharing. Departments do not consistently host all or any of their data in the UDP.

The Citywide Integration Layer and the Unified Data Platform serve different functions. The integration layer supports data exchange between operational systems, while the Unified Data Platform supports enterprise reporting, analytics, and authorized data sharing. A common integration layer can also provide a standardized way to move data from operational systems into the Unified Data Platform, reducing reliance on separate data feeds.

The City expects legacy and modern integration methods to coexist for some time. File transfers, batch processes, and database connections will continue to be required for systems that do not support modern APIs. At the same time, the City wants to expand the use of secure, documented APIs where systems can support them. A citywide integration approach should support existing integration methods while allowing the City to adopt more standardized API-based integration over time.

Why an Integration Platform A platform provides what individual system-to-system connections cannot deliver on their own:

• Connects modern applications alongside legacy systems that lack APIs, supporting file transfers, database connections, and batch jobs alongside real-time API-based integrations

• Translates and routes data between systems with different protocols, formats, and data models

• Orchestrates business processes that span multiple applications

• Centralizes security, authentication, monitoring, logging, and error handling across all integrations

• Establishes consistent governance and visibility across the integration landscape

3. Current Challenges

City departments face persistent challenges with the current approach:

• Legacy constraints: Many critical systems of record rely on file transfers, batch jobs, or custom connectors.

Even where APIs exist, they are often limited or not yet in use. Integration approaches vary significantly by system. Any solution must support these methods, not just modern API-based integrations.

• Decentralized integration architecture: Departments build one-off integrations using different technologies, patterns, and approaches because there is no shared integration infrastructure. This results in duplicated effort, inconsistent implementations, and growing technical debt.

• Inconsistent governance and standards: Integration patterns, security controls, monitoring, data definitions, error handling, and governance practices vary significantly across departments, making integrations difficult to maintain and scale.

• Fragmented operational data: Departments often maintain separate copies of operational data, which can create inconsistencies between systems and complicate cross-department reporting and data sharing.

• Limited operational visibility: When integrations fail, there is no centralized way to monitor data movement, diagnose failures, or understand system dependencies, slowing incident response and increasing operational risk.

• Limited API and integration development capacity: Many departments lack the engineering resources or specialized expertise needed to develop and maintain APIs and enterprise integrations. Even where modern

Sourcing Event ID: 0000011996 3 of 20 August 10, 2026 integration approaches are preferred, limited capacity often results in delayed implementations, continued reliance on manual processes or legacy integration methods, and inconsistent adoption across departments.

Governance Context

• Integration moves data but it does not authorize access of that data. Data flowing through the platform remains subject to the City's data governance framework: data sharing agreements must be in place before access is provisioned, data custodian approval is required for source system data, and applicable review and classification requirements apply. The platform enforces these controls rather than bypassing them.

• Compliance: Centralized logging, monitoring, and audit trails show what data moves between which systems, under whose authorization.

4. Objectives

The City is seeking solutions that can:

• Connect legacy systems and modern applications through a common platform, supporting file transfers, batch jobs, and APIs

• Standardize integration patterns and simplify how integrations are built and maintained

• Improve monitoring, security, governance, and operational support across the integration landscape

• Support reliable, governed data movement into the Unified Data Platform

• Reduce long-term costs through reusable services and shared capabilities and pre-built connectors for common systems and protocols (e.g., databases, HTTP APIs)

• Enable departments, including those with limited engineering capacity, to integrate their systems more efficiently through reusable services, standardized tooling, and shared platform capabilities

• Enable the City to build, operate, and maintain the integration platform using internal staff by providing manageable administration, reusable components, and minimizing reliance on ongoing custom development or vendor-specific expertise

• Scale to support future modernization, including the citywide API layer

5. Areas of Interest

The City is seeking technology solutions that support the following capabilities. Partial and targeted submissions are welcome, as are joint vendor partnerships that combine complementary capabilities.

5.1 Core Integration Engine

The platform should support legacy integration methods alongside modern, API-based and event-driven patterns, including:

• File-based and batch integrations, including flat-file transfers, SFTP, scheduled batch jobs, and database connections for systems that do not support modern APIs

• Real-time and event-driven integration, including event streaming, publish-and-subscribe messaging, webhooks, and other asynchronous patterns

• API-mediated integration using REST, SOAP, GraphQL, and other commonly used standards

• Bidirectional and multidirectional data exchange, including the ability to write authorized data and transactions back to systems of record

• Workflow and process orchestration across multiple applications and organizational boundaries

• Data transformation and mapping between disparate schemas, protocols, formats, and data models

• Error handling, retry logic, dead-letter queues, exception management, and failure alerting

• Secure connectivity to cloud-hosted, customer-managed cloud, and on-premises systems

• Secure, standards-based connectivity to the City’s Unified Data Platform, including Snowflake

• Reusable connectors, templates, services, and integration patterns

Sourcing Event ID: 0000011996 4 of 20 August 10, 2026

• The ability to scale across increasing numbers of integrations, events, departments, users, and workloads without requiring significant architectural changes

5.2 Identity Resolution, Data Quality, and Conflict Management

Many City use cases require linking records across systems that use different identifiers, data structures, or standards. The City is interested in platforms that support:

• Cross-system identity resolution, including matching records that refer to the same person, organization, location, or entity without relying on a common identifier

• Configurable matching rules, confidence thresholds, and human review for uncertain matches

• Data validation and quality enforcement at the point of integration

• Duplicate detection, deduplication, and record reconciliation

• Conflict resolution when different systems contain inconsistent or competing information

• The ability to designate authoritative systems or fields and establish update precedence rules

• Exception workflows for records that cannot be matched or reconciled automatically

• Data normalization across systems configured differently by individual departments

• Controls that prevent inaccurate, unauthorized, or malicious updates from propagating across connected systems

5.3 Security, Access Control, and Compliance

The City handles sensitive information across many integration use cases, including protected health information, criminal justice information, homelessness services data, benefits information, workforce records, and other confidential data.

Proposed solutions should support:

• Role-based and attribute-based access controls governing which users, systems, departments, and applications may access specific integrations and data flows

• Fine-grained permissions for viewing, creating, modifying, approving, or administering integrations

• Integration with City identity and access management systems, including single sign-on and multifactor authentication

• Encryption in transit and at rest

• Tokenization or pseudonymization of sensitive data elements

• Secure credential, certificate, secret, and encryption-key management

• Comprehensive logging of data access, transfer, modification, administrative actions, and failed access attempts

• Secure multi-tenancy and departmental isolation

• Controls for external partners, vendors, and community-based organizations connecting to City systems

• Consent and authorization controls where required

• Data classification and policy enforcement

• Secure integration with systems subject to HIPAA, CJIS, HMIS, State of California social services privacy and security requirements, and other applicable legal, contractual, or regulatory requirements

• Controls that restrict unauthorized data access, use, replication, or movement across environments

5.4 Monitoring, Observability, Reliability, and Recovery

Departments need confidence that integrations are functioning as intended and timely visibility when failures or performance degradation occur.

The City is seeking capabilities that include:

Sourcing Event ID: 0000011996 5 of 20 August 10, 2026

• Real-time dashboards showing integration health, transaction volumes, error rates, latency, throughput, and system dependencies

• Alerting for failed, delayed, degraded, or anomalous integrations

• End-to-end tracing of transactions and events across multiple systems

• Centralized logs and searchable audit trails

• Service-level tracking and performance reporting by integration, department, and service

• Self-service tools that allow authorized staff to investigate and resolve common errors without engineering support for every incident

• High availability and resiliency, including elimination or mitigation of single points of failure

• Automated failover, fault isolation, retry, and graceful degradation capabilities

• Backup, business continuity, and disaster recovery capabilities

• Defined recovery point and recovery time capabilities appropriate to critical operational integrations

• Support for testing failover and recovery procedures without disrupting production operations

• Access to operational logs, metrics, traces, and telemetry in open, vendor-neutral formats

5.5 Developer and Administrator Experience

The platform should support a range of users, from central platform administrators to departmental technical staff and implementation partners, with capabilities appropriate to their respective roles and responsibilities.

The City is interested in:

• Low-code and configuration-based tools that reduce the need for custom development

• Support for custom code where necessary for complex integrations

• A library of pre-built connectors for common applications, databases, protocols, and systems represented in the City’s current environment

• Clear API references, technical documentation, integration templates, and onboarding materials

• Development, testing, staging, and production environments

• Automated testing, validation, deployment, and rollback tools

• Version control and change management for integrations, connectors, APIs, schemas, and workflows

• Lifecycle management for reusable integration assets, including versioning, deprecation, and retirement

• Collaboration tools that allow central platform administrators and departmental technical teams to work within appropriate permissions

• Tools for estimating, monitoring, and optimizing resource consumption and platform costs

5.6 Multi-Tenancy and Departmental Isolation

Multiple City departments are expected to share this platform, each with distinct data, workflows, and administrative needs. Departments should be able to operate independently without compromising the security or performance of others.

The City is interested in:

• A shared-services model in which a central team operates the platform and departments consume its capabilities

• Department-specific workspaces, environments, permissions, and administrative roles

• Mechanisms allowing departments to manage their own integrations without accessing another department’s data, credentials, configurations, or workflows

• Central enforcement of citywide security, architecture, monitoring, and governance standards

• Delegated administration with appropriate oversight and auditability

• Separation of development, testing, and production environments

• Usage metering, reporting, cost allocation, and chargeback capabilities

Sourcing Event ID: 0000011996 6 of 20 August 10, 2026

• Support for different operating models, including City-operated, vendor-operated, and co-managed environments

5.7 Data Ownership, Portability, Interoperability, and Governance

City data and City-funded integration assets must remain under City control throughout the contract lifecycle.

The City is interested in platforms that support:

• Export of City data in documented, machine-readable, and non-proprietary formats

• Portability of configurations, schemas, mappings, workflows, APIs, connectors, and other integration assets

• Migration to another platform or service provider without unreasonable technical, contractual, or financial barriers

• Clear data retention, transition, and deletion capabilities at contract termination or non-renewal

• Native metadata management, cataloging, and data lineage

• Visibility into the source, destination, transformation, ownership, and authorized use of data moving through the platform

• Governance workflows for data classification, stewardship assignment, access approval, and policy enforcement

• Support for open standards and non-proprietary interfaces that reduce vendor lock-in

• Interoperability across multiple cloud environments, technology vendors, and integration tools

• APIs and interfaces that allow City-developed applications and services to access platform capabilities

• Separation of City-owned integration logic and configurations from proprietary platform components

6. Current Systems and Integration Context

The following table describes key systems in the City's current landscape. This list is not exhaustive but is intended to help vendors understand the integration environment. The City is open to proposals that connect to, replace components of, or supplement any of these systems.

System / Function

Tool Department Notes for Vendors Use Cases

Resident and Service Delivery Systems Homeless Management Information System (HMIS)

Online Navigation and Entry (ONE) System (Clarity Human Services SaaS product)

San Francisco Department of Homelessness and Supportive Housing (HSH)

Primary system of record for homeless services. Community-Based Organizations (CBOs) providing City-funded services maintain parallel records in their own systems that need to sync to

ONE.

1, 2, 3, 4

Electronic Health Records

(EHR)

Epic Systems Department of Public Health

(DPH)

Primary System of Record (SOR) for health data. Health Insurance Portability and Accountability Act (HIPAA-regulated);

Business Associate Agreement (BAA) required for any vendor handling Protected Health Information (PHI) in connection with this system. Key source and target for clinical data integration.

Used in clinical settings across the City and County of San Francisco, including

2, 3, 4, 5

Sourcing Event ID: 0000011996 7 of 20 August 10, 2026

System / Function

Tool Department Notes for Vendors Use Cases for behavioral health coordination. Target for real-time data sharing.

Information about Epic’s APIs and interface specs: https://open.epic.com/

Electronic prehospital care reporting (ePCR)

ESO San Francisco Fire Department

(SFFD)

State-mandated SOR for community paramedicine and fire incident records.

Pre-set data model and data dictionary;

limited customization.

Legacy ePCR Health Record Management System (HRMS)

SFFD Prior Electronic Health Record (EHR) system, still in use for some SFFD operations. More configurable than ESO.

Conservatorship case management

Panoramic Department of Disability and Aging (DAS) / Human Services Agency (HSA)

SOR for clients under the jurisdiction of the Public Conservator.

HSA case management

Launchpad (Salesforce)

Human Services Agency (HSA)

Custom application built on the Salesforce platform managing client services across HSA programs, including employment services through the Workforce Development Division.

Department-specific configurations in use.

Grants management

CitySpan Various Used for grant applications and contract compliance tracking across multiple departments. Each department operates its own CitySpan configuration with no shared data model across departments.

Emergency rental assistance

Dataverse Mayor’s Office of Housing and Community Development

(MOHCD) /

San Francisco Department of Homelessness and Supportive Housing (HSH)

SOR for SF Emergency Rental Assistance Program (ERAP) applications and payments.

311 resident services

Verint 311 Citywide intake and case management platform for resident service requests.

Field service management

Connected Worker App (ConnectedBits)

311 Mobile app for frontline staff to receive, document, and close 311 service requests with photo capture. Integrated with Verint.

CBO partner case management

Various (Salesforce, CaseWorthy)

CBO-owned Systems operated by individual CBOs providing City-funded services. Not City-https://open.epic.com/

Sourcing Event ID: 0000011996 8 of 20 August 10, 2026

Function

Tool Department Notes for Vendors Use Cases owned; integration requires active CBO collaboration and will vary by partner.

Field data capture / outreach

Outreach Worker Tool

(OWT)

DPH / HSH Mobile application used by street outreach teams. Currently provides read-only access to client data; desired state involves write-back to ONE and EPIC via the integration platform.

Real-time availability and intake tracking

CareConnect San Francisco Police Department

(SFPD) /

Sheriff's Dept

App used by SFPD Officers, Sheriff's Deputies, and Intake Staff at the RESET Center. Supports real-time chair tracking and availability; automated documentation for §647(f) (public intoxication) and §849(b) (release without charge) encounters; and property tracking with custody transfer workflows.

Computer-aided dispatch (CAD)

CAD Systems SFFD Primary dispatch and incident management system. CJIS-regulated.

Source system for Fire-to-OCC data sharing.

Emergency incident management

ReddiNet Department of Emergency Management

(DEM)

Emergency incident management system.

Source for acute care event data used in PSH client care coordination.

Assessment management

Property Tax Systems (PATS) and System for Managing, Assessments, Records, and Transactions

(SMART)

Assessor- Recorder

(ASR)

System for managing records, assessments, and transactions

Permitting OpenGov Various – e.g., Planning, Building Inspection, SFFD, Port

Online permitting system 7

Location-based property information

Property Information Map (PIM)

Planning Department

Online geographic information system (GIS) search tool providing a map of San Francisco properties and associated zoning, permit, complaint, and appeal histories

Enterprise and Internal Business Systems Document management / informal SOR

SharePoint Various Used across departments as a fallback when primary SORs do not support specific workflows (e.g., care plans stored as Word documents).

Enterprise Resource Planning (ERP)

PeopleSoft Controller’s Office (CON)

Citywide HR, financial, budget, payroll system of record.

Sourcing Event ID: 0000011996 9 of 20 August 10, 2026

Function

Tool Department Notes for Vendors Use Cases

Unified Data Platform

Snowflake DataSF Enterprise analytics and reporting platform. The integration layer must support delivering data to Snowflake through secure, standards-based mechanisms.

Identity and Access Management

Oracle OCI IAM, Oracle Access Governance, Oracle API Gateway, Microsoft EntraID / Beyond Trust

(PAM) /

LexisNexis, Active Directory, AD Manager

Department of Technology

(DT)

Citywide Enterprise Identity IAM platform Access Management (single sign-on), Identity governance, Privileged Access Management, Device MFA, Identity Proofing, API gateway management through Oracle and/or Microsoft.

Sourcing Event ID: 0000011996 10 of 20 August 10, 2026

7. Use Cases

The use cases below are illustrative rather than exhaustive. They are intended to represent a range of operational integration challenges, architectural patterns, and regulatory environments that the City expects a shared integration layer to support.

Use Case 1: CBO-to-ONE Data Sync Current state: Community-based organizations (CBOs) providing homeless services use their own case management systems. Currently, client data must be manually entered in both the CBO system and ONE (the City's system of record for homeless services). Staff spend significant time on duplicate entry, and data in ONE is often incomplete because CBOs do not consistently perform the manual sync.

Desired state: Client data captured by CBOs in their own systems automatically syncs to ONE via the integration platform. Staff do not need to manually enter data in two places. ONE reflects current, complete data from all CBO partners. In the long-term, CBOs funded by multiple city departments can provide data that automatically syncs to multiple city systems via the platform.

Systems involved: Multiple third-party CBO case management systems (varied vendors) and ONE (Bitfocus).

Integration patterns tested:

• Bidirectional sync between external third-party systems and a City system of record (potentially multi-directional in the long term)

• Cross-system identity resolution for clients who exist in both systems with different identifiers

• Security across organizational boundaries: secure authentication, authorization, audit logging, and protection against unauthorized data modification when integrating with external partner systems Demo scenario: Demonstrate how the platform establishes and secures bidirectional synchronization between an external third-party system and the City's integration layer. Describe the authentication, authorization, and trust model used to protect data exchanged across organizational boundaries. Demonstrate how the platform handles identity resolution when a client exists in both systems with different identifiers, prevents unauthorized updates, and surfaces synchronization failures through monitoring and audit logs.

Use Case 2: Outreach Worker Tool Write-Back Current state: Street outreach teams use the Outreach Worker Tool (OWT) for read-only access to client data, but capture encounter notes and field observations in multiple disconnected systems: ONE, EPIC, and MS Forms.

Data from different systems never comes back together. Staff manually re-enter the same encounter information across platforms.

Desired state: OWT gains write functionality. Data captured in the field via OWT is automatically written back to ONE (and potentially EPIC) via the integration platform in real time. A single point of data capture replaces multiple manual entries.

Systems involved: Outreach Worker Tool (mobile/field data capture) writing to ONE (Bitfocus) and EPIC (DPH).

Integration patterns tested: Event-driven write-back from a lightweight field application to multiple systems of record; schema transformation between systems with different data models.

Demo scenario: Show event-driven write-back triggered by a record creation or update in a source application.

Demonstrate schema transformation between two systems with different data models. Show how the platform handles write failures and surfaces errors to the originating system.

Use Case 3: Acute Care Data Linkage for PSH Clients Current state: Case managers supporting clients in Permanent Supportive Housing (PSH) have no visibility into when their clients experience nonfatal overdoses, are placed on 5150 involuntary psychiatric holds, are admitted to emergency departments, or enter Lanterman-Petris-Short conservatorship proceedings. They learn about acute events through informal communication or after the fact, making coordinated clinical response difficult.

Sourcing Event ID: 0000011996 11 of 20 August 10, 2026

Desired state: When a PSH client has an acute care event (nonfatal overdose, 5150 hold, ED admission, inpatient hospitalization, conservatorship filing), the integration platform alerts their PSH case manager with relevant clinical data in real time, enabling coordinated response and housing retention planning.

Systems involved: DEM emergency incident management system, DPH clinical systems, hospital and emergency department data, HSA conservatorship records, and HSH’s ONE system that includes PSH case management.

Integration patterns tested: Real-time alerting across agency boundaries; cross-system clinical data linkage involving HIPAA-regulated health records; strict access controls to ensure PSH case managers see only their own clients' data.

Demo scenario: Show real-time event notification triggered by a clinical event in a source system, delivered across an organizational boundary to a second application. Demonstrate access control enforcement: show that only the authorized case manager for a given client receives the alert. Demonstrate audit logging for the data transfer. Discuss how the platform supports BAA requirements.

Use Case 4: Real-Time Bed Availability Current state: HSH-managed shelter bed availability is available in the ONE System and can be accessed by street teams. However, availability across the broader network of shelter, behavioral health, residential treatment, and partner-operated capacity remains fragmented across systems and providers. Staff may need to consult multiple sources or coordinate manually to identify an appropriate placement, slowing decisions and reducing confidence that availability information is current.

Desired state: A real-time, aggregated view of shelter and residential/treatment capacity from both HSH and DPH, updated continuously. Street teams can see live bed availability and make placement decisions in the field without making phone calls.

Systems involved: HSH ONE System and DPH residential capacity systems, feeding into CareConnect.

Integration patterns tested: Real-time data aggregation from two independent source systems with different update frequencies and data models; low-latency streaming for live decision support.

Demo scenario: Show real-time data aggregation from two source systems into a single target view. Demonstrate how the platform handles differences in update frequency between sources. Show latency characteristics.

Describe how the platform would handle a source system outage without degrading the availability view entirely.

Use Case 5: Fire-to-OCC Integration Current state: SFFD responds to 911 calls and maintains records on high-acuity individuals who repeatedly use emergency services. DPH's Office of Coordinated Care (OCC) provides behavioral health coordination for these same individuals but has no visibility into SFFD call data, and similarly SFFD community paramedicine captains do not have visibility into OCC clinical services/data. The two systems are completely disconnected, preventing coordinated response and contributing to repeat 911 and other emergency system utilization.

Desired state: When SFFD encounters a high-acuity individual, relevant data is shared in real time with DPH OCC to enable a coordinated behavioral health response. Shared visibility reduces unnecessary 911 calls and supports better outcomes for high-utilizers.

Systems involved: SFFD CAD system (CJIS-regulated) and/or SFFD’s EHR writing to EPIC, DPH OCC clinical coordination platform (HIPAA-regulated) and vice versa.

Integration patterns tested: Real-time bidirectional event streaming from a CJIS-regulated source system to a HIPAA-regulated target; dual compliance requirements; cross-agency access controls and audit logging across organizational boundaries.

Demo scenario: Show real-time data sharing from a source system subject to one compliance regime (e.g., CJIS) to a target system subject to a different regime (e.g., HIPAA). Demonstrate how the platform enforces the access control and audit requirements of both frameworks simultaneously. Show cross-agency audit trails. Describe how the platform would be configured to ensure data is only shared with authorized staff respectively.

Sourcing Event ID: 0000011996 12 of 20 August 10, 2026

Use Case 6: PeopleSoft ERP Timekeeping Integration Current state: PeopleSoft is the City’s authoritative system of record for employee, payroll, and organizational data. Departments may also use separate systems for scheduling, timekeeping, and other workforce functions.

Integrations between these systems and PeopleSoft are often custom-built or file-based, and some processes require staff to manually upload, validate, or reconcile records. Workforce changes in PeopleSoft, such as hires, transfers, position changes, and separations, also need to be shared with authorized downstream systems.

Desired state: PeopleSoft remains the authoritative system of record for enterprise workforce and payroll data.

Approved departmental systems exchange data with PeopleSoft through managed integrations, including scheduled processing where required for payroll. Workforce changes in PeopleSoft are distributed to authorized downstream systems without requiring separate integrations for each application.

The integration should support validation, reconciliation, exception handling, correction workflows, and applicable internal control requirements. It should also allow the City to transition from file-based and custom interfaces toward secure, reusable API-based integration patterns as systems modernize.

Systems involved:

• PeopleSoft (Controller's Office) as the authoritative enterprise system of record for workforce and payroll data

• Approved departmental scheduling and timekeeping systems (e.g., Kronos/UKG or equivalent)

• Authorized downstream workforce and operational applications that consume PeopleSoft workforce data

Integration patterns tested:

• Governed bidirectional exchange between approved enterprise systems and PeopleSoft using secure APIs or managed integration services

• Scheduled, payroll-aligned processing of workforce and timekeeping transactions

• Event-driven propagation of authoritative workforce changes to multiple downstream systems

• Integration with a legacy enterprise system that relies on file-based, database-level, or SOAP interfaces while supporting a transition to modern API-based integration patterns Demo scenario: Show how the platform connects to a legacy enterprise system (simulated PeopleSoft environment) and propagates a workforce event, such as a new hire or position transfer, to multiple downstream systems in a single triggered workflow. Demonstrate how time records from a departmental timekeeping system are batched and transmitted to PeopleSoft on a payroll-aligned schedule. Show error handling and alerting when records fail to sync before a payroll deadline. Indicate where adjustments are applied when a mistake occurs during current pay period and after the pay period has ended. Describe how the platform would manage the transition from file-based integration methods to API-based patterns as downstream systems modernize.

Use Case 7: Unified Property Information

Current state: Property-related information is maintained across multiple City systems, including assessment records, permitting systems, geographic information systems (GIS), inspections, code enforcement, and departmental business applications. While many of these systems reference the same physical properties, they often use different identifiers, data models, update schedules, and integration methods. As a result, staff frequently need to search multiple systems independently to understand the history, status, or characteristics of a property. Information is duplicated across systems, updates do not consistently propagate between applications, and new systems often require custom point-to-point integrations to access property information.

Desired state: Property information can be exchanged between authorized City systems through the citywide integration layer. Updates from authoritative sources, such as assessment, permitting, and GIS systems, can be distributed to multiple downstream applications without requiring a separate point-to-point integration for each system. The integration layer should also account for differences in property identifiers and data structures across systems. Relevant property data should be able to flow to the Unified Data Platform for reporting and analytics.

Systems involved:

• Property Tax Systems (PATS) and System for Managing Assessments, Records, and Transactions (SMART)

• Property Information Map (PIM)

• GIS and addressing services

• OpenGov and additional permitting, inspection, and property-related systems as appropriate

Sourcing Event ID: 0000011996 13 of 20 August 10, 2026

• Unified Data Platform (Snowflake), as an authorized downstream destination for standardized property and permitting data

Integration patterns tested: Event-driven synchronization of authoritative property updates; API-based access to shared property information; location- and parcel-based identity resolution across systems; data transformation between systems with different schemas and identifiers; reusable APIs supporting multiple downstream consumers; integration of legacy and modern applications through a shared platform; parallel delivery of operational events and standardized data to operational consumers and the Unified Data Platform; governed, monitored ingestion into Snowflake using reusable integration patterns; reconciliation between source-system transactions and data delivered to the Unified Data Platform Demo scenario: Demonstrate how the platform receives an authoritative property update, such as a permit issuance or property record change, and distributes that update to multiple downstream systems. Show how the platform resolves different property identifiers, transforms data where required, and handles errors or conflicting updates. Also show how the same source data could be delivered to the Unified Data Platform for reporting and analytics.

8. Vendor Scope and Responsibilities

8.1 In Scope for Respondents

The City welcomes responses from organizations that provide technologies or services supporting the capabilities described in Section 5. This may include, but is not limited to:

• Enterprise integration platforms and related integration technologies

• API management platforms with operational integration capabilities

• Implementation, configuration, and migration services

• Managed services or operational support

• Relevant experience implementing comparable solutions in large, multi-department or multi-agency organizations

Respondents are not required to address every capability or use case described in this RFI. The City welcomes responses that address the full scope of the RFI as well as submissions focused on specific capabilities or areas of expertise.

8.2 Joint Responses Welcome

The City welcomes joint responses from multiple organizations. Respondents may combine complementary capabilities, including platform technology, systems integration, implementation services, service design, and change management. Joint responses should clearly identify each participating organization and describe the roles and responsibilities of each party.

9. Response Requirements

9.1 Submission Requirements

Responses consist of two components, both due by the deadline identified in this RFI:

Written Response: Submit a PDF to Amanda.Wentworth@sfgov.org with the subject line "Citywide Integration Layer RFI." Written responses should be no more than 25 pages (including appendices, if any) and address the sections below.

mailto:Amanda.Wentworth@sfgov.org

Sourcing Event ID: 0000011996 14 of 20 August 10, 2026

Demonstration Video: In addition to the written response, the city is strongly encouraging a demonstration video for responses proposing a technology platform. In a joint response, the platform provider should lead the demonstration. Respondents proposing only implementation, advisory, or managed services should describe the services offered and may submit a relevant demonstration or case study in lieu of a product demonstration. The video should be no more than 20 minutes.

The purpose of the demonstration is to illustrate how the proposed solution would address real City operational integration scenarios. The City is interested in understanding how the respondent would configure, implement, operate, monitor, and govern the proposed solution in the context of the use cases described in Section 7 rather than viewing a general product demonstration.

Each respondent should select at least two use cases from Section 7. The selected use cases should demonstrate different integration patterns (for example, event-driven integration, bidirectional synchronization, API-based integration, or scheduled processing).

For each selected use case, respondents should demonstrate the corresponding Demo Scenario identified in Section 7. Where applicable, demonstrations should illustrate:

• How the integration is designed or configured

• The end-to-end movement of data or events between systems

• Authentication, authorization, and security controls

• Data transformation and mapping

• Monitoring, logging, and operational visibility

• Error handling, retries, and recovery from failures

• Administrative and governance capabilities

• How reusable assets (connectors, workflows, APIs, templates, etc.) would be leveraged

• Any assumptions, limitations, or product capabilities that are not demonstrated. Unless otherwise specified, respondents should assume that City systems may have limited APIs, inconsistent identifiers, fixed batch windows, incomplete documentation, and constraints on modification.

Demonstrations should focus on the respondent's actual platform capabilities. Marketing videos, slide presentations, or high-level product overviews without a scenario-based demonstration are discouraged.

Videos may be submitted as an unlisted link (e.g., YouTube or Vimeo) or as an attached file.

9.2 Respondent Information

Provide:

• Company overview and years in operation

• Primary point of contact

• Relevant public sector experience from the last 12 months

• At least two references from organizations of comparable size or complexity, including at least one multi-department or multi-agency implementation

9.3 Solution Overview

Describe the proposed solution and how it addresses the City's need for a shared operational integration layer.

Sourcing Event ID: 0000011996 15 of 20 August 10, 2026

Include:

• Overall solution architecture

• Primary platform capabilities

• Deployment model (SaaS, customer-managed cloud, on-premises, hybrid, or other)

• Product maturity and roadmap

• Relevant government implementations

• Key differentiators of the proposed solution

• Architectural approach and rationale for why the proposed solution is well suited to the City's operational integration needs.

• Any significant capabilities described in Section 5 that require custom development, third-party products, or planned future functionality rather than being available natively.

• Tradeoffs with your architectural approach

9.4 Implementation and Operating Model

Describe how your solution would be implemented, operated, and supported in a large, multi-department government environment.

Include:

• Recommended implementation approach and high-level implementation phases

• Typical implementation timeline for an organization of comparable size and complexity

• Recommended operating model (vendor-operated, City-operated, or co-managed)

• A responsibility matrix identifying ownership for:

o Platform administration o Integration development and connector maintenance o Source-system coordination o Monitoring and incident response o Data quality remediation o Disaster recovery o User onboarding and training

• Required City staffing, technical skill sets, and ongoing operational responsibilities

• Any implementation assumptions, dependencies, or organizational considerations the City should understand

9.5 Security, Compliance, and Governance

Describe how your proposed solution addresses the security, privacy, governance, and regulatory requirements described in Section 5.3.

Include:

• Your approach to identity and access management, encryption, audit logging, monitoring, and data governance.

• Experience supporting environments subject to HIPAA, the FBI Criminal Justice Information Services Security Policy, HUD Homeless Management Information System privacy and security requirements, State of California social services privacy and security requirements, or comparable requirement

• Any relevant security certifications or independent assessments (e.g., SOC 2 Type II, FedRAMP, StateRAMP, ISO 27001).

• Any support, administration, development, or operational functions performed outside the continental United States.

Sourcing Event ID: 0000011996 16 of 20 August 10, 2026

For solutions supporting Protected Health Information (PHI) or Criminal Justice Information (CJI), describe your experience implementing solutions in those environments and the operational controls used to meet applicable regulatory requirements.

Respondents should be aware that San Francisco bars using Facial Recognition Technology with limited exceptions under Administrative Code Section 19B and such technology may not be used as part of any proposed solution.

9.6 Resource and Cost Estimates

Provide high-level estimates for:

• Software licensing

• Implementation services

• Ongoing support and maintenance

• Expected staffing requirements for both the vendor and the City

• Major assumptions affecting implementation effort or cost

• Estimated licensing model (per connector, per transaction, per user, capacity-based, etc.)

General cost ranges are sufficient. Formal pricing is not expected as part of this RFI.

9.7 Data Ownership and Portability

Describe how your platform supports long-term City ownership of data and integration assets, including:

• What happens to City data upon contract termination or non-renewal, including export formats, timelines, and any associated costs

• The portability of configurations, data models, and integrations built on the platform, should the City migrate to another solution

• Native metadata management and data lineage capabilities, including how lineage is captured and surfaced to non-technical users

• How the platform supports governance workflows such as data classification, stewardship assignment, and access approval

9.8 Strategic Considerations (Optional)

Respondents are invited to provide perspectives on any of the following:

• Significant changes in enterprise integration technology or architecture that the City should consider over the next three to five years.

• Architectural, implementation, or governance decisions that have the greatest impact on the long-term success of a shared integration platform.

• The organizational capabilities and staffing needed to operate and expand a shared integration platform in a decentralized environment.

• Emerging capabilities, including AI agents and automated workflows, that may affect how systems integrate or access data, and any associated security or governance considerations.

9.9 Showcase of Products (Optional)

Following review of RFI responses, the City may invite vendors to participate in a solution showcase.

Sourcing Event ID: 0000011996 17 of 20 August 10, 2026

10. Important Notes

• This RFI is issued solely for information gathering and planning purposes. It is not a Request for Proposals (RFP) and does not constitute a solicitation or commitment to contract.

• Information provided in responses may be used to develop future solicitations, which may differ significantly from the scope described here.

• The City is under no obligation to issue a solicitation or award a contract based on this RFI.

• All submissions become the property of the City and County of San Francisco and may be subject to disclosure under the California Public Records Act and the San Francisco Sunshine Ordinance, unless exempt. Respondents should clearly identify information they believe constitutes a trade secret or confidential proprietary information.

• Respondents are solely responsible for all costs associated with preparing and submitting responses. The City assumes no financial obligations as a result of this RFI.

11. Questions and Answers

For questions regarding this RFI, please submit inquiries via email to amanda.wentworth@sfgov.org by the deadline noted in the timeline above. The City strongly discourages respondents from submitting Questions written by AI. While the City agrees that AI has many productive uses, these questions should reflect an expert’s assessment of the RFI and its fit for your products and / or services. The City reserves the right to decline to re-answer questions that are answered in the RFI, or questions that are not relevant to the problem space. We may also group similar questions and provide a single response. Questions and Answers will be posted with the RFI material following the Questions due date.

mailto:amanda.wentworth@sfgov.org

Sourcing Event ID: 0000011996 18 of 20 August 10, 2026

Appendix A: Cybersecurity Standards Should the City proceed to procurement following this RFI, bidders will be required to participate in the City's Cybersecurity Risk Assessment (CRA). The CRA may be required for each entity manufacturing the product, performing technical functions, or accessing City networks and systems. To conduct a CRA, the City will request one of the following:

• SOC 2 Type 2 Report

• ISO/IEC 27001

• CSA STAR…