Business rule for attachments not triggering from email updating the incident

Go to solution
WillZ1880654930
Tera Contributor

3 weeks ago

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".

Preview file
45 KB
0 Helpfuls
  • 836 Views
1 ACCEPTED SOLUTION

Go to solution
Vikram Reddy
Tera Guru

3 weeks ago

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

View solution in original post

0 Helpfuls
5 REPLIES 5

Go to solution
dmanno
Tera Contributor

a week ago

I had a similar issue, but determined that when an emailed attachment is added to an incident, it actually does this as an UPDATE, not an INSERT.

 

I believe the logic is as follows:

  1. Email processor creates a sys_attachment record ("Table name" = sys_email) and sys_email_attachment record.
  2. The OOB email processor checks to see if a sys_attachment record with the same hash exists on the target table record (Incident in my case).
  3. If an attachment with the same hash does not exist on the target (Incident) record, the sys_attachment and sys_email_attachment rows are UPDATED.
    1. The sys_attachment record "Table Name" is changed from "sys_email" to "incident", the "Table sys ID" is changed to the sys_id of the Incident and the "Updated On" is updated.
      1. I noticed a 1 second difference between create and update time as evidence of the update.
    2. The sys_email_attachment record is updated with "Action" = "Attached to Target Record".
  4. If an attachment with the same hash does exist on the target (Incident) record, only the sys_email_attachment row is updated.
    1. The sys_attachment is left unchanged ("Table Name" = sys_email).
    2. The sys_email_attachment "Action" is set to "Filtered From Target Record".

 

After quite a bit of investigation and effort, the final solution was a simple change. All I had to do was rebuild my Flow trigger to look for "Table name" = "incident" for both Insert (when a user adds an attachment to the incident manually) and Update (when the attachment is added by OOB email processing) operations.

0 Helpfuls