We are excited to announce the launch of Service Bridge for PSDS (Public Sector Digital Services), now available as an essential add-on for Public Sector customers. This powerful tool redefines how government agencies collaborate, offering a seamless, secure, and systematic way to orchestrate and manage services across the ServiceNow ecosystem.
The Core Challenge: Eliminating Swivel-Chairing
Across government, many national, federal, state, and local agencies operate with their own dedicated ServiceNow instances. While PSDS is the foundational CRM product for government, enabling seamless agency-to-agency service delivery across these separate instances has traditionally been difficult.
Interagency cooperation today is often dependent on manual, error-prone processes like email, phone calls, or "swivel-chairing" information between systems. Conversely, building custom integrations or implementing e-bonding is typically time-consuming and costly. From an end-user perspective, navigating multiple portals across different departments leads to fragmented experiences and portal fatigue.
What value does Service Bridge deliver?
Service Bridge directly addresses these challenges by connecting multiple ServiceNow instances to provide seamless support and service experiences across the Public Sector.
Service Bridge delivers significant value to Public Sector customers by orchestrating and improving collaboration within the government ecosystem. This enhanced cooperation allows Providers (service-offering agencies) to receive and fulfill service requests in their own instances, leading to higher quality services and faster responses to requesters.
It dramatically reduces the overall cost-to-serve by maximizing automation and government employee productivity using systematic, structured tasks passed across the connection. Moreover, Service Bridge eliminates the need for slow, expensive, and error-prone custom e-bonding integrations with other government departments and partners alike. Finally, it offers faster onboarding, as new and updated service entitlements can be published quickly to subscribed customers’ service catalogs.
Service Bridge for PSDS is available for PSDS Pro and Enterprise tiers only as an add-on SKU.
Public Sector Use Cases: Solving Customer Pain Points
Service Bridge for PSDS is strategically designed to deliver a frictionless connection for agencies and foster crucial interagency cooperation across departments, suppliers, partners, and other entities.
Shared Services: Orchestrated Government Operations
Shared services refer to centralized, standardized solutions that multiple government agencies (Federal, Local, State) can consume to improve efficiency, reduce duplication, and streamline operations. These services typically encompass common administrative or technical functions like HR and payroll, financial management, IT, or grant management. Service Bridge facilitates this model by enabling Shared Service Providers (SSPs) to deliver these functions to consuming agencies. This allows agencies to scale out services as needed without having to develop custom solutions internally, enabling them to focus on their core missions.
Coordinating Emergency Response
Emergency response inherently involves complex, multi-agency processes where constituents need assistance from various groups (e.g., FEMA, state housing, and local health services). Service Bridge enables simple integration between FEMA’s portal and the ServiceNow instances of relevant state and local agencies. When a citizen submits a disaster assistance request through FEMA's portal, Service Bridge uses its Remote Task capabilities to automatically generate corresponding tasks in the State Emergency Management Agency system. These real-time data sharing and coordinated workflows ensure all parties are synchronized, reducing redundancy, expediting aid delivery, and transforming response into a cohesive, constituent-centric network.
Bridging the Gap: A Unified Constituent Experience
One pain point in government service delivery is the fragmented experience constituents face when trying to complete related tasks, forcing them to navigate multiple departments, websites, and logins. Service Bridge addresses this by connecting a single constituent-facing portal (Consumer Portal Instance) with various internal agencies (Providers) responsible for fulfillment. Residents access services (permits, licenses, benefits) through one unified interface. Crucially, Service Bridge coordinates the tasks and workflows across the separate fulfillment instances, enabling true end-to-end service delivery while allowing fulfillment departments to continue working efficiently within their own instances.
Technical Functionality and Core Architecture
Service Bridge operates using two primary applications: Service Bridge for Providers (installed by the agency offering the service) and Service Bridge for Consumers (installed by the agency receiving the service), which is free to install.
The provider initiates the process through a quick registration task to establish a secure, bi-directional connection between the instances. All communication between the connected instances utilizes Remote Process Sync (RPS) integration. When exchanging data, Service Bridge sends the information to a central transport queue, specifically the Service Bridge Transport Queue (sn_transport_queue). RPS then processes the inbound payloads and places them in the transport queue on the receiving instance for Service Bridge to process the updates. Data exchange takes place over secure, private channels, ensuring encrypted transfer between data centers.
Key Features Driving Collaboration
- Remote Catalog (Remote Record Producers - RRP): Providers define and publish service catalogs, known as Remote Record Producers (RRPs), from their instance. These RRPs appear natively in the consumer's Service Portal. When an end-user submits a request via the RRP on the consumer instance, a lightweight, unique Provider Task is created on the consumer side. This Provider Task is replicated on the provider's instance, triggering a flow that creates a related fulfillment task, such as a case, incident, or change request. Updates and comments are then synchronized bi-directionally between the Provider Task and the fulfillment task, providing the consumer with visibility into progress. Note that Service Bridge currently only supports catalog items utilizing Record Producers, not those using Playbook on Portal.
- Remote Task: This feature serves as a sustainable replacement for custom e-bonding by enabling the bi-directional linking and synchronization of tasks (e.g., Incident to Case) across separate instances. Remote tasks rely on Remote Task Definitions (RTDs), which allow fields to be mapped and synchronized bi-directionally, transmitting comments, attachments, and mapped fields between instances. Remote Tasks can be triggered or initiated from either the provider or the consumer side based on configured triggers.
- Provider Task: The Provider Task is a lightweight, unique task record specific to Service Bridge that requires zero setup on the consumer side. Providers leverage this capability to send Proactive Cases (notifications or alerts) to consumers. This is typically triggered by an alert related to an onboarded customer in the provider's instance, creating a case and automatically generating a Provider Task in the consumer's instance for real-time transparency and collaboration.
- Remote Choice: To eliminate the need for costly foundational data replication, Remote Choice allows consumers direct access to real-time choice data for a catalog reference field directly from the provider's instance when filling out an RRP. This ensures that the consumer is referencing accurate, up-to-date provider data, such as CMDB Configuration Items (CIs).
- Transform Framework: The transform framework enables both providers and consumers to translate or transform inbound and outbound data values, such as State or Priority fields, as data moves between instances. This capability is critical because providers and consumers often have different value choices or processes for the same field. The framework supports several types of transforms, including: Simple (for known, stable choice lists where one value maps to one value); Advanced (used for complex criteria that requires a script to determine the new value); and Virtual Inbound/Outbound (used when a field doesn’t exist on the receiving instance, requiring a script to transform and create the data). Additionally, the Scratchpad feature allows the sharing of additional structured data (name-value pairs as JSON) associated with Provider Tasks and Remote Tasks, enabling structured data exchange.
FAQ
Do we support customers in Regulated and self-hosted or on-premise environments (GCC, FedRamp, Impact Level 5)?
- Yes, Service Bridge supports protected instances that support RPS.
- Yes, self-hosted and on-premise instances are supported by Service Bridge.
What’s on the roadmap for Service Bridge for PSDS?
Service Bridge will continue developing its capabilities, and we will inherit Service Bridge’s releases.
Do both instances (provider/consumer) need to be at the same major platform release version?
No, Service Bridge supports the N-2 release of support standards for ServiceNow. Both the provider and consumer instances can run at any of these major release versions.
