How can i get data out of a data pill post Yokohama

[LonLandry1]

I have noticed an issue post Yokohama release.

Simple custom actions that I built no longer work in flows.

The actions work, all logs are as expected when testing the action, but always fails in flows because the data pill (output from the action) seems empty - log messages go empty or undefined.

I was able to create custom actions with custom scripts before the Yokohama release.

Inputs

Script step

(function execute(inputs, outputs) {
// Log the entire inputs object for debugging
gs.log("Inputs: " + JSON.stringify(inputs));

// Check if table and field inputs are provided
if (!inputs.table || !inputs.field) {
throw new Error('Table and field inputs are required.');
}

// Retrieve the table sys_id and field from inputs
var tableSysId = inputs.table;
var field = inputs.field;

// Retrieve the table name using the sys_id
var tableRecord = new GlideRecord('sys_db_object');
if (!tableRecord.get(tableSysId)) {
throw new Error('Invalid table sys_id: ' + tableSysId);
}
var tableName = tableRecord.name;

// Log the table name for debugging
gs.log('Table name: ' + tableName);

// Retrieve the sys_id(s) from the lookup records action
var sysIds = inputs.sys_ids;

// Log the sys_ids for debugging
gs.log('sys_ids: ' + JSON.stringify(sysIds));

// Check if sysIds is defined and not empty
if (!sysIds) {
throw new Error('sys_ids input is required.');
}

// Split the sys_ids by new line or comma
var sysIdsArray = sysIds.split(/[\n,]+/);

// Log the sysIdsArray for debugging
gs.log('sysIdsArray: ' + JSON.stringify(sysIdsArray));

// Initialize an array to store the field values
var fieldValues = [];

// Iterate through each sys_id and retrieve the corresponding field value
sysIdsArray.forEach(function(sysId) {
var record = new GlideRecord(tableName);
if (record.get(sysId.trim())) {
var fieldValue = record.getValue(field);
gs.log('Field value for sys_id ' + sysId + ': ' + fieldValue);
fieldValues.push(fieldValue);
} else {
gs.log('Record not found for sys_id: ' + sysId);
}
});

// Log the field values for debugging
gs.log('Field values: ' + JSON.stringify(fieldValues));

// Set the output as an array of strings
outputs.field_values = fieldValues;

// Log the output for debugging
gs.log('Output field_values: ' + JSON.stringify(outputs.field_values));
})(inputs, outputs);

end of script step ----

I have also tried using Output type of array.string & array.object...

I opened a HI case but ServiceNow will not address because custom code is involved.

I guess that means ServiceNow allows but does not support custom actions used in Flow Designer.

Pretty crappy on ServiceNow's part if you ask me - they system is too rigid and returns data not helpful to humans, sys_id s as opposed to something identifiable by a human. 

[LonLandry1 · Accepted solution]

Flow designer post Yokohama displays empty data pills if the pill is the result of a custom action. The pills will work as expected when testing but will not work in a flow.

[Lon Landry4]

Nothing official, just results of our testing. Because the custom actions involve scripts. ServiceNow has stated they will not help us understand the issue. We have tried extremely simplified scripts to confirm the issue.

In custom actions that do not involve scripts, we found new payload values being returned in data pills. We found that if a value contains a string the system automatically appends "processed:" to the beginning of the payload. We are in the process of identifying how ServiceNow is appending different value types. We found that flows stopped working because there were now new values being returned that are appended with system created data. ServiceNow does not seem to think this is an issue.

As a workaround we are removing the system appended text before checking if a value returned meets a condition.

[Mark Manders]

I have custom actions (with scripts) running on Xanadu, Yokohama and Zurich (all different clients) and we don't have any issues.

What is the official standpoint of ServiceNow on the fact that it worked before the upgrade and stopped working after it? Something changed on the way the OOB Flow is handling your custom actions, so they can't hide behind 'custom code'. They made it so your custom code is no longer working.

[LonLandry1 · Accepted solution]

I look forward to the upcoming ability to debug custom scripted actions.

[Dino D]

Is this the script you were talking about in this post? https://www.servicenow.com/community/developer-forum/why-is-servicenow-set-on-displaying-garbage/m-p...

I'm curious on what this script is meant to do. It looks like its just pulling information, is dot walking not an option?

I see you have a bunch of logging but can you wrap it in a try catch to see if you can log where its running into an issue. If you're getting undefined, which line is undefined in the logs. I doubt you can share the exact logs with me but I might be able to help.

The only thing I have to go on is you're script and this screenshot. So i apologize if I'm asking basic questions, I just need to understand what I am looking at.

Are you able to tell me what is feeding this flow and what is coming out?

   - I assume nothing is coming out hence your frustration.

This is weird to me 

  // Check if table and field inputs are provided
  if (!inputs.table || !inputs.field) {
    throw new Error("Table and field inputs are required.");
  }


//...

 // Retrieve the table name using the sys_id
  var tableRecord = new GlideRecord("sys_db_object");
  if (!tableRecord.get(tableSysId)) {
    throw new Error("Invalid table sys_id: " + tableSysId);
  }

If its being fed a record, your input might already contain this information and I am not a fan of searching the the sys DB objects if you already have this information being fed in, but I don't know your requirements. 

It looks like your script is asking for the table and then searching for it but I could be wrong.

Id like to see if I can recreate it in a PDI just need to know what is feeding it.