Support configurable ServiceNow target table (#5251)

[adhati09]

Description

This PR allows Open OnDemand to deliver support tickets to custom ServiceNow tables (such as Cases / sn_customerservice_case) in addition to standard IT Incidents.

Previously, the ServiceNow client hardcoded /api/now/table/incident and attachment table_name: 'incident'. This change introduces a table configuration key under servicenow_api that defaults to 'incident' for complete backward compatibility.

Fixes #5251

Changes Made

• Added @table = config[:table] || 'incident' in ServiceNowClient#initialize.
• Updated table creation API endpoint to /api/now/table/#{@table}.
• Updated attachment creation payload to pass table_name: @table.
• Added unit tests in ServiceNowClientTest covering default fallback (incident) and custom table configuration (sn_customerservice_case).

Configuration Example

Administrators can now target custom tables in config/settings.yml:

support_ticket:
  servicenow_api:
    server: "[https://example.service-now.com](https://example.service-now.com)"
    table: "sn_customerservice_case"

[johrstrom]

This is not the API for cases. Not sure where you got this from, but it doesn't appear to be right given the documentation I'm reading.

I suspect you're trusting the AI a little too much. One just told me something similar, but a glance at the actual documentation, now and table are not part of the URL path.

https://www.servicenow.com/docs/r/api-reference/rest-apis/case-api.html

[adhati09]

Thank you for catching that! Updated the endpoint from the Table API to the ServiceNow Case API (/api/sn_customerservice/case).

[johrstrom]

We need to continue to support incidents. Beyond just the URL, the actual payload may change as well.

[adhati09]

Updated create to dynamically route between the Case API (/api/sn_customerservice/case) and Table API (/api/now/table/#{@table}) based on configuration so incident creation continues to work.

[johrstrom]

Seems like we can get rid of :table if we don't need it.

[adhati09]

Kept :table here since @table is used to determine whether to hit the Case API or Table API endpoint.

[johrstrom]

I think a better configuration name could be used, maybe record_type that defaults to incident and probably should do so even when something other than ['case', 'incident'] is supplied.

[Bubballoo3]

I haven't done any experimenting with the ServiceNow API in development, can you share the steps/configs you used to get this working for OSC?

[adhati09]

Hey @Bubballoo3 ,

Here are the steps and configuration details I used to test the ServiceNow API locally for case-based reporting:

1. ServiceNow Instance & Credentials

Used a ServiceNow Personal Developer Instance (PDI) (or OSC dev/sandbox instance) so production data remains untouched.

Verified that the API user account has write/create permissions for the target table (e.g., sn_customerservice_case instead of default incident).

2. Local Dashboard Configuration
   Added the target table and API credentials to your local ondemand.d configuration (or environment variables):

YAML

config/ondemand.d/support.yml

support_ticket:
widget: "servicenow"
servicenow:
instance: "devXXXXX" # Your dev/sandbox instance subdomain
table: "sn_customerservice_case" # Target table being tested
username: "<dev_api_user>"
password: "<dev_api_password>"
3. Testing & Verification

Start the local Rails server (bin/rails s).

Navigate to the Help -> Report Issue / Contact Support form in the dashboard and submit a test submission.

Open your ServiceNow dev instance in the browser and check the target table list (sn_customerservice_case_list.do) to confirm the case record was generated with the correct fields.

Let me know if you hit any endpoint issues or permission errors while setting up your test instance!