Hi @LonLandry1 

• Before Yokohama, Flow Designer was lenient: you could set outputs.field_values = someArray and Flow Designer would try to coerce it into the declared output type.

• Post-Yokohama, the platform enforces strong typing. If your action’s Output is defined as Array.String, then the object assigned to outputs.field_values must be a proper JavaScript array of strings—not a GlideRecord value, not an object, not undefined.

(function execute(inputs, outputs) {
var sysIdsArray = (inputs.sys_ids || '').split(/[\n,]+/).map(function(s){return s.trim();});
var fieldValues = [];

var gr = new GlideRecord(inputs.table_name); // <-- pass table_name directly instead of sys_id if possible
sysIdsArray.forEach(function(sysId) {
if (gr.get(sysId)) {
var val = gr.getValue(inputs.field);
fieldValues.push(val ? String(val) : '');
}
});

// Safe output
outputs.field_values = fieldValues; // must match Array.String
})(inputs, outputs);

No luck. ServiceNow does not seem to want any values displayed outside of sys_id s.

ServiceNow seems to be getting more anti-human every day.

In the end all we want is to be able to see something other than a sys_id - which is useless to a human.

The recent Yokohama breaks dozens of our flows that have worked for years and stops ServiceNow from being legible.

Do you have some SN documentation that verifies and explains this, or is this just your experience?

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.