OOB Approval Business Rule Fails for Non-Catalog Approvals Due to Direct cat_item Reference

[Roshnee Dash]

I think there may be an OOB Business Rule defect : SP_SPNT_SN_INT_CreateWorkNoteOnRITM

The Business Rule is configured on the Approval [sysapproval_approver] table, but its condition does not restrict the source table. However, within the script it directly references:

current.document_id.cat_item.toString();

This assumes that the source record always contains the cat_item field, which is not true for every table. As a result, when approvals are generated from tables that do not have a cat_item field, the script fails.

Because of this failure, the expected work notes are not updated for approvals originating from other source tables. Additionally, the logic appears to have been designed specifically around the sc_req_item table, making it dependent on fields that are not universally available across all approval sources.

I believe the Business Rule should either:

• Restrict execution to tables where cat_item exists (e.g., sc_req_item), or
• Include proper validation before accessing current.document_id.cat_item to avoid script errors for other source tables.

So what's your view on it?

[Ankur Bawiskar]

@Roshnee Dash 

I didn't find that BR in my PDI and also not in one of our vendor instances

seems it's custom BR and not OOTB

💡 If my response helped, please mark it as correct ✅ and close the thread 🔒— this helps future readers find the solution faster! 🙏

[Mark Manders]

Please let us know what plugin/application introduced this BR on your instance, since it's not on any of the instances I have access to. 

Next to that: if there is a defect on something OOB, why not report it to NowSupport so they can fix it?

[Roshnee Dash]

Hi @Mark Manders ,

It was under the SailPoint Identity Security Cloud Service Catalog (x_sap_intidn) scope. However, even when I try to update the approval record from a different scope, I still encounter the same error.

Before raising a HI case, I just wanted to confirm whether this behavior is expected or if it could be an issue with the platform.

[Mark Manders]

If a scoped application introduces logic on OOB tables and there is nothing in the condition to limit it running on OOB logic, there is an issue with the app.

However, your question stated "I think there may be an OOB Business Rule defect" and this is not an OOB business rule. The app you mention is created and sold by SailPoint and is not a ServiceNow (scoped) application. That means that you will have to take this up with SailPoint, although I wonder how they got that rule through the certification process, since it seems to run on the approval table without any safeguards.

I could be wrong here, since the only thing about the BR you shared was that one line and your own analysis. But based on that, I would reach out to SailPoint to get it fixed.