Service Bridge Consumer - Wants a REQ/RITM Created from Remote Record Producers

Sara40
Tera Contributor

5 hours ago

I have a Consumer that submits Remote Record Producers, but they want their side of the process to create a REQ/RITM so that their end users have a consistent portal experience. Is there any way to change or force some logic on their side so a REQ/RITM is created and shown to the end-users instead of the CON?

Sara40_0-1768848068308.png

 

This is a huge deal for them. I'm curious how others have addressed this type of change when converting from customer owned catalog items to Remote Record Producers for the same thing. We are transitioning from the Consumer & Provider both having e-bonding with hard coded mappings over to Service Bridge and this is the primary gap we still have is that the user experience changes.

 

0 Helpfuls
  • 92 Views
1 REPLY 1

Itallo Brandão
Giga Guru

5 hours ago

Hi Sara,

This is a very common friction point when migrating from legacy e-bonding (Local Items) to Service Bridge (Remote Items).

The Short Answer: You generally cannot (and should not) force a Remote Record Producer to create a sc_req_item (RITM).

The Technical "Why": A valid RITM record inherently requires a reference to a local Catalog Item definition (sc_req_item.cat_item).

  • In the Remote Record Producer model, the definition only exists on the Provider instance.

  • Because there is no local sc_cat_item record on the Consumer side to link to, creating a RITM would result in an "orphaned" record (no variables, no item reference, broken portal widgets).

The Recommended Solution: Fix the UX, not the Table The CON record (sn_service_bridge_consumer_request) is designed to replace the RITM wrapper for remote requests. Instead of trying to change the backend table, you should configure the Portal to make the CON record look and feel like a RITM.

You can achieve "experience parity" by configuring the Standard Ticket Configuration for the CON table:

  1. Navigate to: Standard Ticket > Standard Ticket Configuration.

  2. Find/Create: Configuration for table sn_service_bridge_consumer_request.

  3. Add Tabs:

    • Info: To show the fields.

    • Variables: (Crucial) Add a tab or section to display the submitted variables (Read-only), just like a RITM.

    • Activity: Ensure comments/work notes are visible.

  4. Ticket Header: Configure the header to show the "State" or "Stage" clearly.

Summary: By tweaking the Standard Ticket view in the portal, you can make the CON ticket virtually indistinguishable from a RITM for the end-user (showing variables, stage, and updates), while keeping the correct Service Bridge architecture intact.

If this response helps you solve the issue, please mark it as Accepted Solution.
This helps the community grow and assists others in finding valid answers faster.

Best regards,

Brandão.

0 Helpfuls