Hi @Scotty88 ,
ServiceNow to ServiceNow
In theory, any option that works for integrating with third-party systems will also work with other ServiceNow instances, but in general we’ll recommend to use one of these more robust OOB options to integrate between two ServiceNow instances:
IntegrationHub Spokes
Remote Process Sync
New in Quebec: The feature IntegrationHub Remote Process Sync enables you to set up one-way or bidirectional integrations among multiple ServiceNow instances so that your process flows stay in sync.
IntegrationHub Process Sync provides you with these benefits:
- Automate cross-enterprise automated processes that span multiple instances, keeping various process stakeholders up-to-date
- Manage how to synchronize and correlate your record, attachment, and journal field data across multiple instances
- Ensure order delivery for data updates in remote instances, using a standalone correlation engine and queueing system
- Manage and troubleshoot errors and outages in your automated mutli-instance processes with Flow Designer's built-in execution engine
ServiceNow Remote Instance Spoke and ServiceNow eBonding spoke
The ServiceNow Remote Instance Spoke provides actions to export, import and manage records when events occur in your local ServiceNow instance. It provides sample transform maps to demonstrate using transform maps to save the remote data in your local ServiceNow tables. This spoke fully replaces the ServiceNow eBonding demo spoke and is available for Orlando instances and up through the ServiceNow Store.
Examples: The ServiceNow Remote Instance spoke can be used if you have several distinct prod instances, for example one external facing with CSM and one for internal workflows. Data transfer will happen conditionally from within a flow. You can also use this spoke to escalate tasks to an external remote ServiceNow instance, for example one that belongs to a service provider who covers your third-party support for a sub-set of your tasks.
ServiceNow eBonding is a demo spoke to show how to sync incidents between two ServiceNow (prod) instances. It is deprecated for instances Orlando and above with the release of the ServiceNow Remote Instance spoke. It uses a basic auth credential to establish the connection and transfers a pre-defined payload of incident data (payloadbuilder script) to the target instance. This spoke could be used as an example to create your own custom eBonding to sync other task types than incident or to sync additional fields if your instance has not been upgraded to Orlando yet.
Instance data replication
Instance data replication (IDR) copies data from a source instance to one or more target instances. It has high flexibility in managing what data is being replicated and under what circumstances. The transferred data can be transformed and mapped to other tables and table columns in the target instances. Business rules can trigger post-replication flows to generate notifications after completion of the transfer. IDR replicates data and not metadata, configurations nor most user and system tables. In contrast to integrating via IntegrationHub spokes (usually REST/SOAP), which are part of business workflows, IDR is not supposed to be transactional. It is purely a means to copy or synchronize data between a producer instance and one or more consumer instances.
On the security side, IDR has significant benefits as it runs on dedicated infrastructure that is integrated with ServiceNow, delivering security, redundancy and support across all data centers. Data that is in transit during the unlikely event of a crash is recoverable.
New in Paris: Bi-directional data replication for customers with multiple instances or service providers with multiple service customers. This feature allows the easy setup and maintenance of a bi-directional IDR configurations within the producer instance and removes the need of maintaining settings in the consumer instances.
Examples: IDR is used to replicate data on an ongoing basis within a replication set of instances. The main use case would be to sync multiple prod instances, for example for large customers or to sync prod data to a UAT instance. Data transform allows modifications by mapping the data, for example localizing it during replication.
System Clone
System Clone is a base platform capability available to all customers. Cloning replicates prod instance data (like users, groups, CIs, and tasks) and configuration to pre-production instances before installing a patch or upgrade to make sure that any resolved conflicts and successful tests will also apply to the prod instance. It also provides the test instance with a real-life set of data to allow for realistic tests when testing new developments on the platform.
New in Orlando: Clone Profiles, Preserve In Progress Update Sets
Examples: Cloning can be used to set up a new or zBooted sub-prod instance with prod data and configuration. It is generally used to prepare your sub-prod for an upcoming release or patch.
