why is current.sysapproval.sys_class_name empty for an approval request to a catalog request?

[ctu1]

Hi,

I have a funny situation, I put in this catalog request and find it generated an event approval.requested that is actaully meant for change task approvals. Looking at the approval events business rule, there should be a different event fired, however that doesnt happen. Then dug into this and somehow the sys_class_name just returns empty...

HELP! Paging for Mark.... 😉

[Mark Stanger]

Now that you mention 'getDisplayName' in your script, I did just see something like this with change request approvals. It wasn't able to drill through to the referenced record from the approval record. You'll need to contact support on this one, but you could try modifying your business rule or email notification mail script a bit to add a specific query based on the sys_id in the 'sysapproval' field. You might be able to get the information you want by querying rather than dot-walking.

[ctu1]

What is very amazing: In the workflow that is creating this approval, I inserted a script action as the very first thing in the workflow. All it does is a current.update() to the sc_request the workflow runs on. And voila, all of my issues (I had a similar situation where a script include could not get at the request items within a request if it was run right after the request was written - seems the "children" were not there yet), including the approval this is all about, disappeared. While I know it is silly to put a script in there that attempts an unnecessary write - it's a working workaround until I get some feedback from support. I will open an Incident for this.

[AnnMarieC]

Thanks for the workaround, that solved the problem. Did you ever hear back from support on this issue?

[Valor1]

You should never add current.update() in a business rule or a workflow--you will end up doing double commits, and will at the very least get duplicated emails.

The better solution to this is to update the OOB approval events business rules to replace "current.sysapproval.sys_class_name" with the following:

current.source_table;

This will return the correct value.

The reason this is happening is that the workflow starts before the record has been inserted into the database, and waits for the Approval to be created. Additionally, the workflow waits for the approval record to be saved to the DB.

Since the BRs on Approval run 'after' (and not 'async', where "previous" is unavailable), the workflow doesn't save the request until after the "approval events" rule triggers. Then, since current.sysapproval (the task to be approved has not been saved to the database yet, the approval events BR is trying to get an attribute of a nonexistent record, and failing. The "source_table" is an attribute of the approval record itself, so it's always valid.