Skip to main content
New Idea

Improve ServiceNow Connector

Related products:CS Connectors
  • April 8, 2025
  • 5 replies
  • 67 views
bradley
Forum|alt.badge.img+8

The ServiceNow (SNOW) connector is a nice idea, but desperately needs improvement as it is borderline unusable in some areas.

The primary issue is what SNOW refers to as “Choice” fields - Dropdowns or picklists in more familiar terms.

The SNOW data is stored in Value:Label pairs. So you might get something like this:

Value Label
1 High
2 Medium
3 Low

 

The way it is currently built, the SNOW connector ONLY sends the “value” portion of this pair, which 9/10 is completely unusable as it is.

This means that even if all you wanted were string values, and not have the choice fields come in as pick lists on the Gainsight side, you still have to hard code every variation from it’s value input to the Label output via Gainsight.

This is completely bonkers and I don’t know how the connector got approved with this functionality. The API has a property that allows the Label to be sent, but the connector does not utilize this.

Anecdotally, it might be possible to turn it on on a per-tenant basis but it slows the job to such a degree as to make it inoperable. 

 

While there are various ways one can map the Value to a Label in Gainsight, choice fields can have very high numbers of options, meaning case transformations (the easiest and quickest OOB method) or not an option. You can to consider that SNOW can be deployed across multiple languages, meaning if you have a list with 25 options in 4 languages with distinct values across all of them, you could potentially have a choice field with 100 distinct options.

 

Possible workarounds and why they are not real solutions:

  • Load the mappings via rules - this is possible but still requires either a regularly maintained S3 file with all the current mappings, or a complicated mapping rule
  • Bring in the Values as-is, and create a lookup table with the value as the lookup key. The main issue with this, aside from creating lots of bloat - is that a Choice value has other properties too: Inactive (yes/no) and Language. You cannot get the language property via the connector, and it is possible to have the same *value* present across multiple languages. They might not even be the same meaning.

 

Please make this connector usable by allowing Choice Labels to be brought in without destroying job run times.

5 replies

J
Forum|alt.badge.img+3
  • Jack_Darley
  • Contributor ⭐️⭐️⭐️
  • April 24, 2025

Not exactly the same topic as choice fields, but it would be great if the transform tasks in the service now connector let you create formula fields. I am bringing in service requests and wanted to use a formula field to create the URL of each service request. However, when you make a transform task, the only type of field you can create is a case field, which will not let me concatenate the general Service Request URl and the sys id. 
Instead of generating the URL in the same process that runs the Service Request Job, I will now need to run a rule in Gainsight to create the URL field and make that rule’s schedule match the schedule of the service request job. 

bradley
Forum|alt.badge.img+8
  • bradley
  • Author
  • Expert ⭐️
  • April 24, 2025

Not exactly the same topic as choice fields, but it would be great if the transform tasks in the service now connector let you create formula fields. I am bringing in service requests and wanted to use a formula field to create the URL of each service request. However, when you make a transform task, the only type of field you can create is a case field, which will not let me concatenate the general Service Request URl and the sys id. 
Instead of generating the URL in the same process that runs the Service Request Job, I will now need to run a rule in Gainsight to create the URL field and make that rule’s schedule match the schedule of the service request job. 

I don’t disagree, but there might be an easier workaround - create the formula field in Data Management on your Case object (or wherever you’re importing to) and you should be able to have a formula that works as a URL at query time when you need it, and not need an additional rule.

J
Forum|alt.badge.img+3
  • Jack_Darley
  • Contributor ⭐️⭐️⭐️
  • April 24, 2025

I didn’t realize I could do multiple concatentions in one field through data management. I did look to data management first, but then didn’t see an option to concat 3 fields / values together… but now see that’s an option
the URL is essentially has 3 parts:   static URL part 1   token sys id    static url part 3  

bradley
Forum|alt.badge.img+8
  • bradley
  • Author
  • Expert ⭐️
  • April 24, 2025

I didn’t realize I could do multiple concatentions in one field through data management. I did look to data management first, but then didn’t see an option to concat 3 fields / values together… but now see that’s an option
the URL is essentially has 3 parts:   static URL part 1   token sys id    static url part 3  

Yea, it’s hidden because you have to select a function in one of your concat field parameters. And the experience is different I believe depending on where you do it. Some examples of ways to tokenize your URLs:

 

 

speacher
  • speacher
  • Contributor ⭐️⭐️⭐️⭐️
  • October 7, 2025

I didn’t realize I could do multiple concatentions in one field through data management. I did look to data management first, but then didn’t see an option to concat 3 fields / values together… but now see that’s an option
the URL is essentially has 3 parts:   static URL part 1   token sys id    static url part 3  

Yea, it’s hidden because you have to select a function in one of your concat field parameters. And the experience is different I believe depending on where you do it. Some examples of ways to tokenize your URLs:

 

 

Hi, wondering if you have an idea on how to create these URLs for Service Now.  I have one linking Salesforce but the Service Now URLS don’t appear to be identifying the accounts in the same way Salesforce does.  Perhaps it’s just our instance but our Service Now URL’s are referencing a random alpha-numeric number that I haven’t figured out how to tie back to the account yet.  What field are you referencing for your Token Sys ID portion of the URL?

Serena Peacher, Business Analyst @ Inovalon
bradley
Forum|alt.badge.img+8
  • bradley
  • Author
  • Expert ⭐️
  • October 8, 2025

I didn’t realize I could do multiple concatentions in one field through data management. I did look to data management first, but then didn’t see an option to concat 3 fields / values together… but now see that’s an option
the URL is essentially has 3 parts:   static URL part 1   token sys id    static url part 3  

Yea, it’s hidden because you have to select a function in one of your concat field parameters. And the experience is different I believe depending on where you do it. Some examples of ways to tokenize your URLs:

 

 

Hi, wondering if you have an idea on how to create these URLs for Service Now.  I have one linking Salesforce but the Service Now URLS don’t appear to be identifying the accounts in the same way Salesforce does.  Perhaps it’s just our instance but our Service Now URL’s are referencing a random alpha-numeric number that I haven’t figured out how to tie back to the account yet.  What field are you referencing for your Token Sys ID portion of the URL?

Are you trying to link to Accounts in ServiceNow? Or to tickets? I haven’t tried making a URL for the former so I can only speculate as both the URL and field you need might be different.

However, from what I can tell each table in SNOW has a GUID/GSID type field that at least in our instance is called sys_id.

So for my case URL I’m grabbing the sn_customerservice_case.sys_id field (format is table.field).

Our account table also has a sys_id field, so I would probably grab the customer_account.sys_id field from our instance for a SNOW account URL (based on the names in our instance).

Keep in mind though, both use cases would have different URLs, because they’re pointing to different tables in SNOW.

Additionally, the case URL functionality was something our SNOW Devs had to set up (or fix, it didn’t work for a while), so it’s possible the same is true for an Account page.

 

Hope that helps!

speacher
Terms & ConditionsCookie settingsAccessibility statement