Handling multiple attachment categories

Hola klevenick2,

You’re right that Jira ultimately stores all of those uploads in the single Attachments collection on the work item. Native JSM doesn’t give you separate Jira attachment fields for “SOW” and “NSM.”

Forms retains which attachment field the user uploaded the file to, and Automation can read those individual form attachment fields by their field keys. Atlassian documents attachment fields as list values and exposes properties such as the attachment ID and name.

So rather than trying to rename files or create separate attachment fields, I’d use the form itself as the categorization layer.

For example, give the two form attachment fields distinct keys, such as: SOW, NSM

Then, from a Forms submitted automation trigger, you can retrieve values such as:

{{forms.last.SOW.name}}

and

{{forms.last.NSM.name}}

The same attachment-field object also exposes the attachment ID, which gives you a reliable way to distinguish files even though Jira displays them all together under Attachments.

For your Google Sheet export, I’d build the POST payload from those form-field values rather than from {{issue.attachment}}, because {{issue.attachment}} only knows that they’re attachments on the work item and loses the semantic distinction you care about.

One thing I would test before building the whole export is exactly what URL representation you need. The form smart values provide the attachment metadata, but if you need a directly usable download URL in the sheet, you may need to construct it from the attachment ID or retrieve the attachment metadata via the JSM API. Atlassian specifically added support for the Forms API to retrieve form attachment metadata, so the mapping itself is natively supported.

So I’d keep your two upload fields exactly as they are and treat their form keys as your SOW/NSM classification. That avoids file renaming entirely and preserves the distinction you need for Automation and reporting, even though the agent view still shows everything together under Attachments.

Thanks,

James

Hello @klevenick2 , 

@James Gamble has the right layer (the form field key is your category; the work item's Attachments collection has no idea which field a file came from), so let me add the two conditions that make it work end to end, because the second one is where this usually breaks.

1. The smart values exist only on one trigger. {{forms.last.SOW.name}} and {{forms.last.SOW.id}} are populated only when the rule's trigger is Form submitted for that form; on any other trigger (work item created, transitioned, scheduled) they return empty, by design, per Atlassian's forms smart values doc: https://support.atlassian.com/jira-service-management-cloud/docs/access-smart-values-for-forms-and-form-fields/. Field keys are case-sensitive and set on each field in the form builder. If you ever need the same data later in the lifecycle, the route is the Forms REST API from a Send web request action, which Atlassian documents here: https://support.atlassian.com/jira/kb/access-forms-data-with-the-forms-api-in-jira-cloud/.

2. Turn the category into a field the export can read. Your CSV export and the Google Sheet integration read work item fields, not form fields, so the rule's job is to copy each attachment's identity into a field of its own:

• Create two text (or URL) custom fields: SOW document and NSM document.
• Rule: trigger Form submitted (your purchase-order form), then Edit work item setting SOW document to {{#forms.last.SOW}}{{name}} | https://YOURSITE.atlassian.net/rest/api/3/attachment/content/{{id}}{{/}} and NSM document to the same shape with NSM.
• The iterator {{#forms.last.SOW}}...{{/}} also handles someone uploading two files into one field: you get both, separated as you choose.

Now the export has "SOW document" and "NSM document" columns carrying the file name and a direct content URL, and the Attachments collection can stay exactly as it is. The /rest/api/3/attachment/content/{id} URL is the documented download endpoint; whoever opens it needs permission on the work item, which is normally what you want for a purchase order.

One check before you rely on it: add a temporary Log action with {{#forms.last.SOW}}{{name}} ({{id}}){{/}} on the first run to confirm the field key resolves; an empty log line almost always means the key differs from the label or the trigger is not Form submitted.