Ebounding of Problem and Change Table

[Vaibhav Ramteke]

Hi Team,
Could you please share any solution or documentation regarding ebounding  for the Problem and Change tables in ServiceNow?
Looking for best practices around relationships, lifecycle, and control.

Thank you

[Dr Atul G- LNG]

Hi @Vaibhav Ramteke 

Problem and Change tables are already inherited from the Task table, and they also include relationships like referenced and embedded fields.

For example:

• In the Change table, you will find fields like Problem

• Similarly, in the Problem table, you can see related Change references.

These are already part of the standard data model and are linked through OOTB relationships.

Could you please clarify what additional detail you are looking for? Are you referring to the lifecycle of these records (like process flow), or are you looking for specific field-level mappings between Problem and Change?

[Tanushree Maiti · Accepted solution]

Hi @Vaibhav Ramteke 

For my project we did  Problem and Change tables ebonding ( including task level) using import set API.

You should have correct mapping list at field level between 2 instances, and you are done.

High level implementation steps:

Step 1: Create an Import Set Table & Transform Map

• Navigate to System Import Sets > Load Data.
• Choose a source (e.g., Load a sample CSV or JSON file containing Change Request fields).
• Create a new Import Set Table named u_change_ebonding.
• After loading the data, click Create Transform Map.
• Set your Source table to u_change_ebonding and Target table to change_request.
• Map your incoming fields (e.g., u_number to number, u_short_description to short_description, u_priority to priority).
• Check the Choice action setting in your field maps to dictate whether values should be ignored, rejected, or created if they don't match standard Choice Lists.

Step 2: Configure the Transform Map Script

To prevent duplicate records and update existing changes during an eBonding back-and-forth, set your coalesce fields:

• Go to your created Transform Map.
• In the Field Maps related list, locate the field representing the external Change ID or correlation ID (e.g., map your u_correlation_id to the target correlation_id).
• Check the Coalesce checkbox for this field.

If you need specific status mapping (like mapping an external state to your target ServiceNow states), add a script to handle it

• Scroll down to the Script tab in the Transform Map.
• Ensure you have the ignore or mapping logic written to translate inbound JSON payloads into standard choice values.

Step 3: Test the Web Service Endpoint

• Navigate to System Web Services > REST > REST API Explorer.
• Under "Select Namespace", choose Import Sets API and select your target table u_change_ebonding.
• Use the POST method. Paste a sample external Change Request payload in JSON format.
• Execute the API. It will return a response status confirming the payload was successfully staged.

Step 4: Automate Outbound Callbacks (Bi-Directional eBonding)

To complete the eBonding lifecycle so the external system knows when the Change Request state changes:

• Navigate to System Policy > Business Rules.
• Create a Business Rule on the change_request table.
• Set the condition to run when the correlation_id is not empty (meaning it's an eBonded ticket) and specific fields change.
• In the Advanced tab, use an Outbound REST message to send an HTTP PATCH or POST call back to the external platform.

Refer:

Ebonding - ServiceNow

https://www.youtube.com/watch?v=XM6DWMu2jA8

https://www.servicenow.com/community/developer-forum/ebonding-between-two-servicenow-instances-a-com...

[Vaibhav Ramteke]

Hello @Tanushree Maiti 
Thank you for your solution and support. 
Its request to can you share your document if you have that related it is very helpful to me.

[Tanushree Maiti]

Hi @Vaibhav Ramteke 

Will create for you and share separately . Ping me tomorrow.