Business rule for attachments not triggering from email updating the incident

[WillZ1880654930]

I have an async BR that runs when a record gets inserted in the sys_attachment table.  The BR works fine when I add an attachment to the incident ticket manually, but it does not trigger when an email updates the ticket with an attachment.  I did confirm the incident record did get a new attachment and the sys_attachment record table name listed it as "incident".

[Vikram Reddy]

Hey @WillZ1880654930,

This isn't your business rule misbehaving, it's documented platform behavior. ServiceNow KB2208821 covers this exact scenario: an After/Insert business rule on sys_attachment does not execute when the attachment record is created through Inbound Action processing, which is the same pipeline that handles files coming in on an inbound email. The row still lands in sys_attachment correctly, that's why you can see table_name = incident on it, but the insert path email processing uses doesn't walk through the scripted business rule engine the same way a manual UI upload does. So your async BR simply never gets invoked for those rows, no matter how the filter condition is written.

// Async "Update" Business Rule on Incident (add a matching one on sc_task)
// When: async, Update

(function executeRule(current, previous) {

    var att = new GlideRecord('sys_attachment');
    att.addQuery('table_name', current.getTableName());
    att.addQuery('table_sys_id', current.getUniqueValue());
    att.orderByDesc('sys_created_on');
    att.setLimit(1);
    att.query();

    if (att.next()) {
        var secondsAgo = gs.dateDiff(att.getValue('sys_created_on'), gs.nowDateTime(), true);
        if (secondsAgo < 30) {
            // attachment landed in this same transaction, run your logic here
        }
    }

})(current, previous);

The idea is to stop listening on sys_attachment and hook into the parent record instead. Inbound email processing still runs an ordinary update on the incident, adding the reply as a comment or work note, after it copies the file over, and that update fires the normal business rule engine without any of the Inbound Action weirdness. Checking for a sys_attachment row created within a few seconds of the transaction is a reliable enough proxy for "an attachment just arrived on this update."

A couple of things worth doing before you rebuild the logic this way:

• Test a record-triggered Flow on the Attachment [sys_attachment] table first. Flow Designer's record trigger uses a different underlying mechanism than a scripted business rule, and it's a five-minute test to see if it catches what the BR misses. If sys_attachment doesn't show up in the trigger's table picker, add it to the glide.ui.permitted_tables system property (comma-separated list) to expose it.
• Confirm the incident actually gets updated by the inbound email in your case, not just the attachment copied over silently. If the email only adds the file and nothing else changes on the incident, an Update BR on Incident won't fire either and you'll need the timing-window check above rather than a plain field-change condition.

Since your original filter condition also covers sc_task, don't forget to replicate whichever fix you land on there too, since Inbound Actions for catalog task updates go through the same attachment pipeline.

Thank you,
Vikram Karety
Octigo Solutions INC