Handling multiple attachment categories

[klevenick2]

Hi all,

I'm building a form through JSM to help people in my company request a purchase order by submitted a ticket to the finance team. In order to process the request, we need a few docs: a statement of work (SOW) and negotiated services memo (NSM). 

Is there a way in native JSM to categorize these appropriately? I have an attachment field on the form for each one, but they attach to the ticket all under the "Attachments" field. When we report on later via csv I'd like to be able to export the SOW attachment's URL under an SOW column (and the same for a NSM). For example: via automation we export a list of all PO requests with their fields, and send it via POST to a google sheet, so it can be compared against another sheet.

I know we cannot create custom attachment fields, but wondering how people may have solved for this. It seems you can't rename a file with automation, only reupload it and delete the original.

[James Gamble]

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

[Olha Yevdokymova_SaaSJet]

Hi @klevenick2 

Yes, this is a tricky one because there are really two layers here: the form knows which attachment was uploaded for which question, but Jira ultimately stores the files together in the standard Attachments field.

With native JSM Forms, you can at least reference an attachment answer from a specific form field in Automation. For example, if your SOW and NSM attachment questions have field keys, {{forms.last.<field key>.name}} can return the attachment name, and the attachment ID is also available. So depending on how your Google Sheets automation is built, there may be a way to use those IDs to distinguish the files before working with the Jira attachments. Atlassian documents attachment form smart values here.

The limitation is the one you've already found: once those files are attached to the work item, Jira doesn't give you separate SOW Attachment and NSM Attachment fields. They're still all Jira attachments.

If you're open to apps, another approach you might consider is Smart Forms for Jira, developed by my team at SaaSJet.

You could have two separate attachment elements:

Statement of Work (SOW) → upload
Negotiated Services Memo (NSM) → upload

Smart Forms keeps each uploaded file associated with the form question it came from. In the Responses view, attachments are displayed under their corresponding question, and when exporting responses to Excel, attachment download links are included with the response data.

For an automated setup like your Google Sheet, there's also an API Data Source whuch you may use as a script directly inside google sheets. It returns the form responses as structured JSON, including the answers for each form element and attachment download URLs. So instead of trying to infer which Jira attachment is the SOW later, you can take the attachment associated with the SOW element and write its URL into the SOW column, and do the same for NSM.

One caveat though: at the Jira work-item level, we're dealing with the same Jira limitation you described — the actual uploaded files still end up in Jira's common Attachments field. We preserve the attachment-to-question relationship in the Smart Forms response data, which makes export/API reporting much easier, but it doesn't create separate native Jira attachment fields.

We're actually looking at this same challenge because categorizing attachments cleanly inside Jira itself is surprisingly tricky.

[Sami Shaik]

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.