How can use a form's attachment field's id to perform different actions with different attachments?

[Pedro Wagner]

I have a requirement  to create a request type that allows a user to upload multiple different attachments that will serve different purposes. I use a Jira form that includes two separate attachment fields. While these attachments remain separated in the form, they are grouped together on the issue anyway

This in itself is not a problem. However, I need to create automations that will take one of these attachments and send it to somewhere, and send the other attachment somewhere else.

The most basic form of it is: Once the form is submitted, I need to create two child issues. One has one of the attachments, and the other has the other.

The attachment field on the form allows me to set a field ID for it, like in the attached image. I wanted to use this field IDs to identify which attachment would be sent where.

However, when I try the create action on the automation, it doesn't allow me to use a smart value with the attachment field. How can I use the attachment field's ID then? Can I use the additional field section? If so, How? And if not, does anyone know any work around I can use to identify which attachment needs to be sent where and how to do it?

[Hamza Chundrigar]

Hi @Pedro Wagner

Welcome to the Atlassian community.

You’re very close. The value you’re setting on the form is useful, but it’s a form field key, not a separate Jira attachment field. That key can tell automation which upload box a file came from, but the native Create work item action can’t copy only the files from Att1. It can only copy the work item’s attachments as a group.

The closest native design I’d use is (if that's what you're going after) - keep the original work item as the file package, then create two child work items that point people to the right files.

1. In the form, keep simple field keys like Att1 and Att2.
2. Create the rule with Forms submitted as the trigger.
3. Add a temporary Log action to confirm Jira is reading the files separately

   • Attach 1:
     {{#forms.last.Att1}}{{name}} ({{id}})
     {{/}}
     
     Attach 2:
     {{#forms.last.Att2}}{{name}} ({{id}})
     {{/}}

4. Add Create work item for child A, but don’t copy the Attachment field.
5. In child A’s Description, add something like:

   • Use these files from the original work item {{issue.key}}:
     
     {{#forms.last.Att1}}
     - {{name}} (attachment id: {{id}})
     {{/}}

6. Repeat for child B with Att2.

That should help give each child work item the correct file list and keeps the original upload in one place, as well as avoids duplicate attachments, wrong deletes, and permission surprises. It also handles the case where someone uploads more than one file into the same form field.

I wouldn’t use More options JSON for the actual file copy. That section is for setting Jira fields through JSON, not for turning one attachment ID into an uploaded file on another work item.

If each child work item must physically have only its own files, there are two workable patterns.

1. a native but fragile option could be requiring a filename convention, for example every file in Att1 starts with att1- and every file in Att2 starts with att2-. Then copy all attachments to each child and use Delete attachments with a filename regex to remove the wrong set from each child. This only works safely if filenames are controlled. Atlassian’s delete action works by matching attachment filenames, so duplicate or inconsistent filenames can remove the wrong file.
2. A more exact but would need some kind of integration where you pass the attachment IDs from {{forms.last.Att1.id}} and {{forms.last.Att2.id}} to an app, webhook service, or middleware. That service downloads the right attachment from the parent and uploads it to the right child. Jira’s REST API has separate endpoints for getting attachment content and adding attachments to a work item.

Hope this helps!

[Pedro Wagner]

Hello! these seem like potential workable options. Having the attachments on their correct child items would be ideal, even if an API is needed

Regarding your first solution, about modifying the description of the child item to refer to the parent item. Can I add a link to the attachment there, next to the name and id? This way, the agent could access it without switching to a different issue

[Hamza Chundrigar]

Yes, you can make each filename a clickable link straight to the file, so the agent never opens the parent. Every attachment in Jira Cloud is downloadable at a stable URL built from its id, and the description renders Jira's link markup. In the child's Description, you can use something like:

Files for this work item (stored on {{issue.key}}):

{{#forms.last.Att1}}
- [{{name}}|https://YOURSITE.atlassian.net/rest/api/3/attachment/content/{{id}}] (id: {{id}})
{{/}}

Two things to know before you trust it everywhere. First, permissions: that endpoint serves a file only to people who can view the work item the attachment lives on, meaning Browse permission on this project, plus issue security if you use it. If your children are subtasks you can ignore this entirely, since subtasks can't leave the parent's project and inherit its security level, so the links work for anyone who can see the subtask. If the children are separate work items, especially in another project, whoever works them needs Browse on this project, so test one link signed in as a regular agent account rather than your own. Admin accounts pass every permission check, which may hide this kind of gap.

Second, a formatting edge: the link markup uses square brackets and a pipe, so a filename that itself contains [ ] or | characters will break that line's link and show as plain text. The id still prints next to it, so nothing should be lost AFAIK, but it's worth knowing if your users upload files with unusual names.

To close out the Additional fields box from your screenshot - that JSON sets field values on the new work item using Jira's REST field format, which is why the hint says the fields must be present on the screen. Attachments can't be set that way; files only land on a work item through the dedicated attachments endpoint or the UI. So it's the right tool for text and select fields at create time, and a dead end for the file copy, which matches what you ran into.

Since you're good with an API being involved for the physical copy, the shape of this thing could look something like this in your rule:

• create child A, then immediately add a Send web request action that posts {{issue.key}}, {{createdIssue.key}}, and the Att1 ids to your service.
• Then create child B and send a second request with the Att2 ids.
  Keep that order, because {{createdIssue}} points at the most recently created work item.
• For the ids, send a plain space-separated string, {{#forms.last.Att1}}{{id}} {{/}}, and split it on the service side; it's cleaner than fighting trailing commas in a JSON array. Log the payload.
• The service itself is two calls per file. GET /rest/api/3/attachment/content/{id} pulls the file down; the response redirects to the file itself, which most HTTP clients follow automatically, and it accepts redirect=false if yours doesn't.

Then POST the bytes to /rest/api/3/issue/{CHILD-KEY}/attachments as multipart/form-data with the header X-Atlassian-Token: no-check. Authenticate with a "service account's" email and API token, and give that account Browse on this project plus Create attachments on the children's project. That's like two HTTP nodes if you're using a automation platform like n8n or Make, or about 30-50 lines of script.

Hope this helps :)

[Pedro Wagner]

Hello Hamza, hope you're well

I was trying out your first solution since it seemed simpler. The child work item was created with the correct file name and link

However, when I click the link, this happens:

I have full permissions to view the original work item. Do you have any idea why this is happening?