Service Exchange - Data Security Summary Now Available

[Phillip Godwin]

If you're evaluating Service Exchange or getting ready to onboard a connected organization, one of the first questions that comes up is usually around security — how data moves, what's protected, and what each side is responsible for.

We've put together a concise technical summary that Service Exchange providers can share directly with prospective consumers. It covers transport and authentication, what data actually crosses the connection, and a clear breakdown of security responsibilities for both sides.

The document is attached to this article below — providers, feel free to share it with any organization you're onboarding or in conversation with.

If you have questions after reading it, drop them in the comments and we'll do our best to help.

[ShaneDXC]

I had a question about section 3 of your document, as I am running into some issues with passing additional data via a Proactive Case (Provider Task) from the Provider instance to the Consumer instance.
In addition to the OOB fields sent from a Provider Case, we are trying to pass some additional fields, including:

• Configuration Item [cmdb_ci] -> Configuration Item [cmdb_ci]
  (the associated CI's are included in FDS from the Provider to the Consumer instance)
• Channel [contact_type] -> Contact Type [contact_type]
• Priority [priority] -> Priority [priority]

How can this be achieved without requiring customization/changes on the Consumer instance?

We are currently running Service Exchange for Providers v2.3.29

[Phillip Godwin]

Hi - this is a question best asked in the technology forum so it others can input and benefit from the answers. I'm interested what piece of this document on SE security prompted you to put the question here?

With that said I'd like to hear more about your use case. So you just want this additional data to be part of the provider task that is sent as the result of an SE Proactive Case so it can be viewed on the consumer side?  Is there any action/trigger planned when the provider task arrives on the consumer instance?

....phil

[ShaneDXC]

As I mentioned, the piece that triggered the query was section 3 in your document that discussed what data moves across the connection.  I was 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 version:
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?

[Kailash Bhange]

Hi @ShaneDXC 

You should be able to do this from the Provider side with configuration only. The consumer just needs to activate the updated definition.

1. On the Provider instance, open the remote task definition used for the provider task that your proactive case sends.
2. On the Outbound fields related list, add one row per field:
- Priority: source priority -> target priority, Sync when = Insert or update
- Channel: source contact_type -> target contact_type, Sync when = Insert or update
- Configuration Item: source cmdb_ci -> target cmdb_ci, Sync when = Insert or update
Use the Source Mapping and Target Mapping tabs to pick the fields (dot-walking is supported on the source).
3. Handle reference and choice values:
- cmdb_ci: if FDS keeps the same sys_id on both sides, the reference maps directly. If not, send something both sides know (for example dot-walk to the CI name or correlation ID) and use an Advanced transform to look up the CI. The docs example for Advanced transforms does exactly this kind of cmdb_ci lookup by correlation ID.
- contact_type / priority: if the choice values differ between the instances, add a Simple transform with value pairs (Service Exchange Provider Administration > Transforms).
4. Publish the definition. On the Consumer side, the updated definition has to be activated (or happens automatically if Auto activate remote task definition is on). This is an activation step, not a customization.
5. Test by creating a new proactive case and checking the provider task / remote task on the consumer.

Caveats:
- The consumer's Service Exchange version must be compatible with the definition, or activation is blocked until they upgrade.
- The consumer can override the suggested Sync when value before activating, so agree on it with them.
- If the fields must land on a record other than the remote task (for example the consumer's incident), check the target table configured on the definition.

If this helps, please mark it helpful, or accept it as the solution if it solves the issue.

[ShaneDXC]

@Kailash Bhange 

You are referring to Remote Task [sn_sb_pro_remote_task] records...

As I stated, we are talking about Provider Task [sn_sb_pro_provider_task] records (and their corresponding Consumer instance Provider Task [sn_sb_con_provider_task] record) and not Remote Task [sn_sb_pro_remote_task] records.

[Kenny Caldwell]

@ShaneDXC currently this can't be done without making a change in the consumer instance. We discussed internally and like the idea so we are adding it to the backlog. Thanks for the question and idea!