Use PDIs? Take our 5-minute survey to help shape the PDI roadmap.

Navex case attachments to automatically feed into its related HR case

Michael Galang
Tera Contributor

Hi Experts, 

We would like the Navex case attachments to automatically feed into its related HR case in Servicenow upon creation or update. Is there a way to configure it without using the Navexspoke? Currently, we are using SOAP message function to pull data from Navex to Servicenow. 

  I would appreciate any feedback regarding this matter. 

Thank you. 

3 REPLIES 3

KPNow
Kilo Guru

Yes, you can configure this without the official NAVEX Spoke. Since you already have a functional SOAP message integration pulling data from NAVEX to ServiceNow, you can extend your existing custom integration logic using ServiceNow’s native APIs.
1. Fetch Attachment Data via SOAP
In your existing SOAP integration script or Business Rule/Scheduled Script Execution, call NAVEX’s attachment web service (e.g., GetAttachment or similar endpoint defined in NAVEX’s WSDL).

NAVEX typically returns the file content as a Base64-encoded string, along with metadata like FileName, ContentType/MimeType, and a unique AttachmentID.

2. Convert and Attach using GlideSysAttachment
Once you extract the Base64 payload from the SOAP response XML, use ServiceNow’s sn_ws.SOAPMessageV2 and GlideSysAttachment APIs to attach the binary directly to the target HR Case record.

Hi , 

Thank you for your response. 
We are having difficulty in making it work. 

The Navex is returning the attachment with MTOM/XOP Packaging as content type and not Base64-encoded string. In this case, what would be the configuration to make it work? 


Thank you very much. 

You can possibly request Inline Base64 from NAVEX

Before writing custom MIME parsing logic, check if NAVEX can return standard inline Base64 instead of MTOM.

  • Request Header / Endpoint: Some NAVEX web service versions allow disabling MTOM packaging via a request header or parameter in the SOAP request payload.

  • Accept Headers: Standardizing the request header to specify standard SOAP content types (text/xml or application/soap+xml) without advertising MTOM support (application/xop+xml) often forces the web service provider to fallback to inline Base64.