--- sourceDocument: Australia Service Exchange sourceDocumentLink: https://www.servicenow.com/docs/r/service-exchange Release : - australia ft:locale : - en-US ft:publication_title : - Australia Service Exchange ft:clusterId : - sebrdg bundleId : - sebrdg workflow : - Customer and Industry --- # Foundation data sync # Foundation data sync {#ariaid-title1} * Release version: Australia * * Updated May 13, 2026 * * ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 2 minutes to read Summarize ![AI sparkle icon](https://servicenow.com/docs/portal-asset/ai-sparkle-icon) Summarized using AI This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete. ## Summary of Foundation data sync Foundation Data Sync (FDS) is a ServiceNow feature that enables structured, scheduled sharing of foundational data between provider and consumer instances. It facilitates accurate, up-to-date exchanges of critical data like server, hardware, and network information to support improved service delivery and operational alignment. FDS supports bidirectional unidirectional data flows, allowing providers and consumers to share data as needed on daily, weekly, or monthly schedules. Show full answer Show less ## Key Features * **Bidirectional Data Sharing:** Two independent flows---consumer-bound (provider shares data) and provider-bound (consumer shares data)---each requiring separate configuration. * **Supported Tables:** Works with all CMDB CI extended tables plus key non-CMDB tables such as Asset, Company, User, Group, Location, Department, Stockroom, Product Model, Knowledge, Hardware Model, Consumable Model, Hardware, Consumable, and Service Organization. * **Data Flow Control:** Providers or consumers define offerings and control which tables, fields, and records are shared; recipients configure how incoming data maps to their instance. * **Service Exchange Compatibility:** Consumer-bound FDS requires Service Exchange 2.2.x or later; provider-bound FDS requires Service Exchange 2.3.x or later. ## Benefits * Automates foundational data sharing to reduce manual effort and eliminate reliance on external data exchange channels. * Provides essential context for operational workflows, improving accuracy and service reliability. * Supports lifecycle management by ensuring foundational data stays current across collaborating instances. ## Practical Use Case For example, a telecom company (consumer) relies on a third-party infrastructure provider. The provider pushes server and network configuration data to the consumer using consumer-bound FDS, ensuring the telecom company can assign users appropriately. In return, the telecom company shares usage data back to the provider via provider-bound FDS, enabling better capacity planning and infrastructure support. ## Configuration Considerations Each direction of data sharing requires separate setup, including defining and publishing offerings and configuring data mappings. Customers can configure FDS as providers or consumers depending on their role in data sharing. Foundation data sync (FDS) enables structured, periodic data sharing from provider to consumer and consumer to provider instances. FDS ensures that both providers and consumers can share and receive accurate, up‑to‑date foundational data, supporting better service delivery and operational alignment. FDS is a data synchronization mechanism that enables a provider instance to share foundational data, such as server, hardware, network information with consumer instances. It also enables consumer instances to share foundational data with provider instances on a scheduled cadence (daily, weekly, or monthly). FDS supports two separate unidirectional data flows, allowing both providers and consumers to act as either data source or recipient depending on the business need: Consumer-bound FDS : Provider shares data with consumer instances. Provider-bound FDS : Consumer shares data with provider instances. Note: These are independent flows. Each flow must be configured separately. Establishing data sharing in one direction does not automatically enable data sharing in the reverse direction. FDS supports all CMDB CI extended tables and the following non-CMDB tables: Asset, Company, User, Group, Location, Department, Stockroom, Product Model, [Knowledge](https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB3063550), Hardware Model, Consumable Model, Hardware, Consumable, and Service Organization. If you need support for any additional table, contact Support. ## Benefits of FDS {#service-bridge-v2-explore-foundation-data-sync__section_ilr_lqy_nfc} FDS supports the service life cycle by enabling providers to share foundational data with consumers in a structured, automated way. This data transfer provides the essential context for operational workflows, reduces manual effort, and eliminates the need to exchange data through external channels. ## FDS data flow scenarios {#service-bridge-v2-explore-foundation-data-sync__section_uqh_kz2_5hc} FDS provides two ways to collaborate by sharing date in either direction: Consumer-bound FDS (Provider shares data) : The provider creates FDS offering definitions and publishes them to make data available. Consumers browse available offerings and request the data they need. After validation and acceptance, data flows from the provider instance to the consumer instance on the defined schedule. The provider controls which tables, fields, and records are shared. Consumers configure how the incoming data maps to their instance tables. Note: Consumer-bound FDS (Provider shares data) is supported from Service Exchange version 2.2.x. Provider-bound FDS (Consumer shares data) : The consumer creates FDS offering definitions and publishes them to make data available. Providers browse available offerings and request the data they need. After validation and acceptance, data flows from the consumer instance to the provider instance on the defined schedule. The consumer controls which tables, fields, and records are shared. Providers configure how the incoming data maps to their instance tables. Note: Provider-bound FDS (Consumer shares data) is supported from Service Exchange version 2.3.x. ## Use Case Example {#service-bridge-v2-explore-foundation-data-sync__section_tty_ly1_1gc} A telecom provider, XYZ company, does not own or manage its own servers. Instead, it relies on a third-party infrastructure provider, ABC company. ABC maintains the configuration data for the servers, including hardware specifications and network dependencies. XYZ needs this data to assign users to the correct servers based on bandwidth requirements. FDS enables ABC to push this data to XYZ regularly, ensuring XYZ has the information it requires to deliver reliable services. In this scenario, ABC is the provider, XYZ is the consumer, and the data flows from ABC to XYZ. ABC company also needs visibility into XYZ to understand the consumption pattern. To enable ABC to provide better infrastructure support, XYZ needs to share data back to ABC. FDS enables XYZ company to share usage data with ABC regularly, enabling ABC to make informed decisions about capacity planning and infrastructure optimization. **Related concepts** * [Configure outbound foundation data sync as providers](https://www.servicenow.com/docs/cS1VnKkPlg2juqOHDhHHNw "As a provider, share foundational data with your consumer using foundation data sync (FDS).") * [Configuring inbound foundation data sync as providers](https://www.servicenow.com/docs/wL~ClDAvOW7FCunNp3bjFg "As a provider, receive the foundation data from your provider using foundation data sync (FDS).") * [Configure inbound foundation data sync as a consumer](https://www.servicenow.com/docs/19lYuMtNE2LP2kB9GWZMrA "As a consumer, receive the foundation data from your provider using foundation data sync (FDS).") * [Configure outbound foundation data sync as consumers](https://www.servicenow.com/docs/ytERBiqNSAbHkISqYlcNMg "Foundation data sync (FDS) consumers share foundational data with a provider by creating FDS definitions, acknowledging requests, and publishing subscriptions.")