Passing additional Provider Task fields to the Consumer and obtaining FDS target sys_id's
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
2 hours ago
(Transferring from post: Service Exchange - Data Security Summary Now Available in search of an answer...)
I am running into some issues with passing additional data via a Proactive Case (NOT via Remote Task) from the Provider instance to the Consumer instance.
In addition to the out-of-box (OOB) fields sent via the Proactive Case process, we are trying to pass some additional fields, from the Case to the Provider Task:
(Provider Instance) Case [sn_customerservice_case] Field | (Provider Instance) Provider Task [sn_sb_pro_provider_task] Field | (Consumer Instance) Provider Task [sn_sb_con_provider_task] Field |
| OOB Fields | OOB Fields | OOB Fields |
| Account [account] | Company [company] | Company [company] |
| Product [product] | Product [product] | Product [product] |
| Short description [short_description] | Short description [short_description] | Short description [short_description] |
| Description [description] | Description [description] | Description [description] |
| State [state] | State [state] | State [state] |
| <Case Record> | Parent [parent] | <Listed as the Provider task [provider_task]: Number only> |
| <Consumer connection record> | Consumer connection [consumer_connection] | <Provider connection [provider_connection] is listed instead> |
| Additional comments [comments] | Additional comments [comments] | Additional comments [comments] |
| <Script: contact.email or account.primary_contact.email> | Requestor email [requestor_email] | Requestor email [requestor_email] |
| Number [number] | Provider task [provider_task] | Provider task [provider_task] |
| <Script, returns Customer Service by default> | Application [application] | <Does not appear to be used, value on target is global> |
| Priority [priority] | Priority [priority] | Priority [priority] |
| <Script including close_notes and resolution_code> | Resolution notes [close_notes] | Resolution notes [close_notes] |
| Additional Fields | Additional Fields | Additional Fields |
| Configuration Item [cmdb_ci] | Configuration Item [cmdb_ci] | ✖ Configuration Item [cmdb_ci] |
| Channel [contact_type] | Contact Type [contact_type] | ✖ Contact Type [contact_type] |
| Actual start [work_start] | Actual start [work_start] | ✔ Actual start [work_start] |
| Actual end [work_end] | Actual end [work_end] | ✔ Actual end [work_end] |
| Correlation ID [correlation_id] | Correlation ID [correlation_id] | ✖ Correlation ID [correlation_id] |
(NOTE: The associated CI's are included in FDS from the Provider to the Consumer instance)
Values pass from the sn_customerservice_case to the sn_sb_pro_provider_task without issue, but primarily, only the original OOB fields seem to pass to the sn_sb_con_provider_task. (Most ✖ fail, but surprisingly Actual Start and Actual end ✔ passed across.)
How can this be achieved without requiring customization/changes on the Consumer instance?
We are currently running Service Exchange for Providers v2.3.29
Also, I am interested to know if the provider instance is able to somewhat independently obtain the consumer target record sys_id utilizing FDS and the associated source sys_id as a component.
A lengthier use case-example version on a targeted value:
From a ServiceNow Service Exchange for Providers v2.3.29 instance...
if we are using FDS to push Configuration Items and their updates to a Consumer instance (without maintaining the same sys_id's), can we utilize the FDS process in combination with PSBScratchpadUtil when creating a provider initiated Proactive Case (Provider Task [sn_sb_pro_provider_task]) record
to ensure the Configuration Item [cmdb_ci] record set on the Provider Task [sn_sb_pro_provider_task] record can properly associate the corresponding FDS Configuration Item [cmdb_ci] record in the Consumer instance associated Provider Task [sn_sb_con_provider_task] (without customizing the Consumer instance) and without knowing with certainty how the target cmdb_ci record is mapped on the consumer instance, whether they processed the FDS data via the Integration Hub ETL / Identification and Reconciliation Engine (IRE) or standard Service Exchange staging mappings or transforms?
