Copy Attachment from Universal Request to Incident
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-16-2023 01:10 PM
Hello,
We started using Universal Request and we have few teams that should receive an Incident right away from Universal Request, this part so far is working fine except for one point, the attachments included in the Universal Request form in the portal are not being copied from UR to INC.
The UI action Create Incident however is working as expected, if there is an attachment in the UR and an INC is create out of that UI action, the attachments and comments are transferred.
Also, I could not find which script is responsible for that copy in the UI action.
Anyone has any idea where should I look?

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-17-2023 12:20 AM
Hey,
You can use the GlideSysAttachment API: https://docs.servicenow.com/en-US/bundle/sandiego-servicenow-platform/page/script/useful-scripts/ref...
GlideSysAttachment.copy('sourcetable','sys_id','destinationtable','sys_id');
Note: This copies all attachments from the original record to the new one.
Regards
Fabian
Ps.: If this was helpful/correct, feel free to mark this answer as helpful/correct. It helps others to find answers quickly.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-17-2023 07:52 AM - edited 08-17-2023 08:04 AM
I did, but it's still not working.
I'm suspecting that the Request Help record producer is creating the INC either before or at same time as the UR is being created. This is happening only when we're selecting the department / service set.
And just to be clear, when the UR is not restricted, our routing agents can use the UI action in the UR form to Create Incident, once the incident is saved, the attachments are copied.
EDIT:
Good news! I've modified the condition When to Run to before_display and now is working!
EDIT 2:
I take back... With the condition like that, every time we open the same incident, it copies the attachment again.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-18-2023 02:41 AM
Hey,
Yeah, the condition should not be set to on_display.
If the business should run for whenever a incident is created with a universal record referenced, this condition must be set to "onAfter". The reason is, that the sys_id for your current incident record is "-1" as long as it isn't inserted into the database. onAfter Business Rules run after the record is inserted into the dabase. Now your incident actually has a sys_id.
Note: you can also use "asynch" as an option. However, if your UI action redirects to the incident, the attachments may not be visible yet (as the asynch business rule could execute after the redirect).
Hope this helps with your issue.
Regards
Fabian
ps.: in any way you should try to have a condition which prevents running the busniness rule more than once. I do believe running on Insert & onAfter is the best option here. Attachments won't get copied though, if the reference to the universal request is made after the incident is created.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-18-2023 12:37 PM
Hi Fabian,
Neither async nor after worked.
I'm suspecting there is something else underneath here. I've found this business rule on Attachment table, called Block Attachment on Universal Request if the primary task is populated.
(function executeRule(current, previous /*null when async*/) {
var gr = new GlideRecord(current.table_name);
gr.get(current.table_sys_id);
if (gr.primary_task) {
gs.addErrorMessage(gs.getMessage("Cannot modify the attachment(s) as there is a primary ticket associated with it"));
current.setAbortAction(true);
}
})(current, previous);
Not sure if this is a good practice, sometimes an attachment must be replaced if is incorrect OR even if the file should not be uploaded.
Don't have much information on this BR so I will have to open a case with SN as there is something else blocking, like ACL.
Sorry I had to mark as not solved yet.