Service Bridge RTD Revision Update for Existing Incidents

[ch_nagireddy]

Hi Team,

We have a Remote Task Definition (RTD) in Service Bridge. Recently, we updated the RTD and created a new revision to fix an issue. The new revision is active and is being used for newly created incidents.

However, incidents that were created before the RTD revision update are still using the older RTD revision that was active at the time of their creation.

I would like to know:

1. Is it possible to update existing incidents/remote tasks to use the latest RTD revision?
2. Does Service Bridge support migrating already-created remote tasks from an older RTD revision to a newer revision?
3. If not supported out of the box, are there any recommended approaches or best practices to achieve this?
4. Has anyone handled a similar RTD revision upgrade scenario in Service Bridge?

Environment: ServiceNow Service Bridge

Any guidance would be appreciated. Thanks!

[Vikram Reddy]

Hi @ch_nagireddy,

No, there's no supported way to move an existing remote task onto a newer RTD revision, and it's not a gap so much as how Service Bridge versions these things. When you publish a new revision, the platform creates what is effectively a separate Remote Task Definition record underneath the same RTD, not an in-place edit of the old one. Remote tasks stay bound to whichever revision was active on the provider side when they were created, so anything opened before your update keeps running against the old revision indefinitely.

The reason ServiceNow doesn't offer a migration path is more than just laziness on the platform's part. Each revision can change the field mapping under object_data.remote_task_var, meaning the variable names the inbound and outbound transforms reference are revision-specific. If you tried to just repoint an existing sn_sb_remote_task record at the new RTD revision, the transform scripts on both sides would be reading fields that no longer line up, and you'd silently break the sync instead of fixing it. There's also a known issue where the trigger configuration on the consumer instance doesn't carry over automatically when a new revision syncs down, which is another sign these are treated as distinct objects rather than versions of one thing.

Given that, here's what I'd actually do:

• Leave in-flight incidents alone if the old revision still functions correctly, let them close out naturally on the revision they started with rather than forcing a switch mid-life.
• If the fix truly must reach an open incident, close out the existing remote task and create a fresh one under the new RTD against the same incident, but know you'll lose continuity of historical work notes/journal sync since Service Bridge doesn't resume journal history sync once a remote task is disconnected and a new one takes its place.
• Test each new revision in a sub-production instance first and avoid auto-activation, so you can fix the trigger and field mappings before it goes live for new incidents.

If this keeps coming up for you operationally, it's worth logging it with Now Support as a product gap, since several people are hitting the same wall with RTD revisioning.

Thank you,
Vikram Karety
Octigo Solutions INC