Service Bridge for Providers/Consumers - promoting configurations from dev/test/prod

[Ryan Palamara]

A common question asked is how to move Service Bridge configuration from a sub-prod instance to a production instance. Below are some best practices for Service Bridge for Providers and Consumers when moving configurations.

Note that this not applicable to Service Bridge (legacy), and only applies to the current Service Bridge for Providers and Service Bridge for Consumers app, that was initially released in November of 2023. 

New in Service Bridge for Providers/Consumers

1. In Service Bridge for the Provider record no longer needs to be the same (ie. Sys ID) across the instances.
2. Configured content can now be packaged in its own Application Scope and is best practice. This was not possible in Service Bridge legacy, since the Service Bridge application scope could not be called on by other application scopes.  This has been updated in Service Bridge for Providers/Consumers, so other application scopes can call on the Service Bridge OOTB objects.
3.   

Provider

1. 1. Application Scopes - It is best practice to create a new application scope to contain Service Bridge v2 configurations. While not mandatory, this will help in development maintenance and follow ServiceNow best practices.
   2. Connections, Connection Settings, Entitlements, and Authorized Users  - Connections, connection settings, entitlements, and authorized users are specific to each pair of instance. They should not be migrated and will need to be established between each pair of instances. 
   3. Provider Record – In Service Bridge for Providers, it is best practice to promote the Provider Record between instances. While it is not mandatory today, there may be relationships in the future. 
   4. Remote Record Producers - For Remote Record Producers, capture the Remote Record Producer (RRP),  RRP Variables, Consumer Criteria and associated custom flows/scripts in the same update set. This is applicable for both new RRPs and updated elements for RRPs. If Remote Choice and/or Personas are being used, ensure that this is migrated either in the same update set as the RRP or prior to the update set containing the associated RRP. 
   5. Remote Task Definitions - For Remote Task Definitions, capture the Remote Task Definition (RTD), Transforms, Field mappings, Consumer Criteria and associated custom flows/scripts in the same update set. This is applicable for both new RTDs and updated elements for RTDs.
   6. Customer Conditions - Customer Condition(s) should be migrated ahead of the Remote Record Producers and Consumer Criteria that they will be used in. Also note that if there are Consumer Conditions filtering based on specific objects, that these objects will need to have the same SysID across the instances, or it will need to be updated post migration.
      1. For example, if you create a Customer Condition filtering on a Sold Product of a specific model, that model will need to have the same SysID across the instances. If it does not, the condition will have to be updated on the destination instance.
        
   7. Consumer Criteria - Consumer Criteria(s) should be migrated either in the same update set as the RRP/RTD or prior to the update set containing the associated RRP/RTD. The Consumer Criteria is a M2M link from a RRP or RTD to a Consumer Condition, so it can be used across multiple RRP/RTD records. It only needs to be promoted between instances once, even if used multiple times.
   8. Personas - Personas should be migrated either in the same update set as the RRP or prior to the update set containing the associated RRP.
   9. Transforms - Transforms should be migrated either in the same update set as the RTD or prior to the update set containing the associated RTD. Transforms should be captured after they have been activated. 
   10. Remote Catalog – Remote Catalog is not currently used in V2 currently and as such not required to migrate.
     

Consumer Instance

1. 1. Application Scopes - It is best practice to create a new application scope to contain Service Bridge for Consumer configurations. While not mandatory, this will help in development maintenance and follow ServiceNow best practices.
   2. Connections, Connection Settings, Entitlements, and Authorized Users  - Connections, connection settings, entitlements, and authorized users are specific to each pair of instance. They should not be migrated and will need to be established between each pair of instances. 
   3. Remote Record Producers – Do not migrate Remote Record Producers (RRP). Currently when published from the provider, they will have different SysIDs in the consumer instances. If there are changes made to the RRPs, such as associated Catalog or Categories, these will need to be updated in each respective instance. Other Service Bridge objects like Remote Task Definitions will maintain their SysIDs. (It is on the roadmap for RRPs to maintain the same sysID). 
   4. Remote Task Definitions - For Remote Task Definitions (RTD), these will be pushed from the provider instance. Once published from the provider instance, you can apply an updates set capturing any modifications made to the Remote Task Definition (RTD), Transforms, Field mappings and associated custom flows/scripts in the same update set. This is applicable for both new RTDs and updated elements for RTDs.
   5. Personas  - Personas cannot be modified and should not be captured in update sets.
   6. Transforms - Transforms should be migrated either in the same update set as the RTD or prior to the update set containing the associated RTD. Transforms should be captured after they have been activated.