Some PDIs are currently unavailable, and PDI actions are paused. View the latest updates here. Read More

Can Remote Instance Spoke or IDR be used to replicate metadata between instances?

GonçaloR
Tera Contributor
I understand that the recommended mechanisms for promoting artifacts between instances are Update Sets, Application Repository, Source Control and CI/CD.

 

However, I am trying to understand the technical feasibility of metadata replication rather than the recommended deployment approach.

 

Has anyone successfully used:

 

- Remote Instance Spoke
- Instance Data Replication (IDR)

 

to replicate metadata such as:

 

- Flow Designer Flows
- Subflows
- Custom Actions
- Business Rules
- Script Includes
- Other application artifacts

 

between ServiceNow instances?

 

I am particularly interested in proof-of-concept implementations, limitations encountered, and whether dependencies between metadata records made the approach impractical.

 

Thanks.
2 REPLIES 2

Daniel Draes
ServiceNow Employee

I would wonder what the use case / scenario is when you want to use this?

 

Technically, those entities are all just records in our database. Which technology you use to move them between instances is not so relevant, i.e. yes, IDR and Remote Process Spoke should be able to transport them. I have never tried and would probably vote against doing that. Some records require special treatment for consistency or cache updates. Just deploying the XML records might miss these steps / dependencies.

Thanks, that's actually what I wanted to investigate.

 

I agree that the technical feasibility and the operational viability are two different questions.

 

I ran a small PoC between two PDIs using Remote Instance Spoke and was able to:

 

- Query remote metadata tables.

- Create Script Includes remotely.

- Create Business Rules remotely.

- Create a Flow record remotely.

 

However, while the Flow record was created and visible in Flow Designer, it was not fully functional because related artifacts such as triggers/actions were not replicated.

 

So far, my findings seem to support your point: these artifacts can technically be transported because they are records, but some of them appear to require additional dependent records and platform processing to remain functional.

 

I'm currently investigating which Flow-related records would also need to be replicated.