This issue is caused by the fact that the record users add attachments to in the portal is not in fact the record being integrated by Unifi. It's a temporary record which ServiceNow will then move the attachments from to the requested item/target record of a record producer at a later time.

An issue arises here though as a Unifi create message can be triggered before ServiceNow moves the attachments. If this happens then Unifi will not send the attachments.

To get around this issue we can trigger a new ServiceNow event to be fired when Unifi sends a create message. This will then give time for the attachment to be added to the request. We will use a script action to then force update any attachments on the requested item, thus triggering Unifi as if the attachment was just added.

Follow these steps:

• Create a new event, say, unifi.send.portal.attachments.on.create

• Create a new Script action, which runs on the above new event, with the following code:

• Modify the create message to trigger the event, i.e. in the Source to stage script of the CreateRequest message, add the following code below the autogenerated scripts:

There has been a change to GlideSysAttachment from when some of our original extract attachments scripts were written, and when now passing the base64 decoded string as a byte array to the global GlideSysAttachment.write() method. Unifi has specialised debugging and because of this, the byte array ends up as null when Unifi debug mode is off. We suspect this is because ServiceNow routes the variable through some coercion in the Rhino environment when passing it through Unifi which forces it to work. Without the debug mode turned on, the byte array is being passed through and for some reason that isn't clear, it is treated differently.

You need to update the extract attachment script to something similar below:

payload = (function extractAttachments(payload, request) {

  function saveAttachment(record, filename, content_type, data) {
    var id;

    if (typeof filename === 'undefined') {
      x_snd_eb.ws_console.warn('Ignoring attachment with missing filename attribute.');
      id = 'x-attachment-error-missing-filename';
    } else if (!filename) {
      x_snd_eb.ws_console.warn('Ignoring attachment with empty filename attribute.');
      id = 'x-attachment-error-filename-is-empty';
    } else {  
      // use x_snd_eb scope to force using the scoped version of GSA
      id = new x_snd_eb.GlideSysAttachment().writeBase64(record, filename, content_type, data);
      x_snd_eb.ws_console.trace('Extracted attachment [' + filename + ':' + content_type + ']' +
        ' to record [' + id + ']' +
        ' for [' + record.getTableName() + ':' + record.sys_id + ']');
    }

    // return the original tag with the sys_id of the new attachment record
    // so Unifi can pick it up in processing later on
    return '[x-attachment-data sys_id="' + id + '" /]';
  }

  var obj = JSON.parse(payload);

  obj.attachment.data = saveAttachment(
    request, 
    obj.attachment.filename, 
    obj.attachment.mime_code, 
    obj.attachment.data
  );

  return JSON.stringify(obj);
})(payload, request);

If you want to send attachments with special characters in their file names, you will need to make sure that you encode the file name first, e.g., using encodeURI(). Here's an example of a standard outbound Unifi attachment stream script with the correct escaping in place.