Why is ServiceNow set on displaying garbage?

[Lon Landry4]

Why does ServiceNow always default to displaying a sys_id, as opposed to something humans can understand?
When the data is displayed on an email for example the data becomes unreadable for users.

Recent changes to flow designer post Yokohama seem to further prevent the viewing of anything but a record's sys_id.  Will ServiceNow continue this anti-human approach with further releases?

If so, how can we ensure users can understand data presented by ServiceNow?

[Bhuvan]

@Lon Landry4 

Can you share more information ?

It is possible that flow is not configured properly, for example whoever configured the email notifications might have just selected the record rather than dot walking and selecting the required fields.

ServiceNow has matured significantly compared to previous releases and as with any products in the market, there might be cons but pros supersede it. 

Thanks,

Bhuvan

[Lon Landry4]

I wasted over 40 hours trying to find a solution. Many custom flow actions that worked in the past no longer work post Yokohama.

Issue seems to be related to the Out of Box look up records action is no longer compatible with custom actions. If you try a simple script where the result would be "a" the system will format your payload to read "processed: a" - so to get your value you would need to regex out the "processed:"
This is just one example of a recent change (before the payload would simply have been "a".)

look up record actions seem to be largely useless with custom actions now because the payload can no longer be read by ServiceNow.

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.

[GlideFather]

Hi @Lon Landry4,

it's interesting :)) your tone is a bit aggressive and what you've described is for the first time when I hear about something similar after 7 years. Let's calm down and discuss it, it seems to me that what you described is a result of misuse or misconfiguration of the platform because ServiceNow has millions of options how to display everything than sys IDs - be it a first name, last name, whatever. Just it's a bit different for a portal form (g_user.userName), backend form (gs.userID().getFirstName()) or notifications ${current.first_name}...

Can you please add any example where ServiceNow is not human readable? 

[Lon Landry4]

So, to recap, we have had workarounds in place to get display names or other column names for flow actions. These custom actions no longer work because ServiceNow has changed data pill output formats (without any supporting KBs). The core issue has always been that ServiceNow returns sys_id s instead of data humans can easily read. Now that ServiceNow is limiting how you can get to data other than a sys_id is frustrating and is counterproductive.