How to add an attachment custom field in Jira Cloud (Jira & JSM)

[#1]

"Can I create a custom field of type attachment?" is one of the longest-running questions in the Jira ecosystem. The original feature request was opened in 2004 and closed as Won't Fix (JRACLOUD-4925) — and new Community threads asking the same thing still appear every few months. This article explains why Jira doesn't have one, what the workarounds actually give you, and how to get a real file upload custom field on Jira Cloud today.

Why there is no native attachment custom field

In Jira, attachments are not a field. They're a separate subsystem for files linked to an issue, and some of its UI just happens to look like a field. That's why the "Attachment" entry you see on screens can't be duplicated, renamed, or scoped the way a select list or a text field can — and why Atlassian closed the request to make it one.

The practical consequences show up as soon as a specific document matters:

• Everything lands in one pile. A signed contract sits next to fourteen debugging screenshots.
• You can't require a specific document. You can require "an attachment", but not "the signed contract".
• No rules per purpose. You can't say "this must be a PDF under 10 MB" for one document and "up to five images" for another.
• You can't search by what's attached where. JQL can tell you an issue has attachments, but not whether the ID scan is missing.

What the classic workarounds give you (and what they don't)

Before reaching for an app, it's worth knowing what's possible natively — for many teams it's enough:

Approach	Good for	Falls short when
System Attachments field on the screen / JSM request form	Collecting any files with a request	You need structure, rules, or more than one "slot"
URL custom field pointing to Drive/SharePoint	Files that must live outside Jira anyway	Permissions diverge from Jira; links rot; nothing is enforced
Paragraph field with a pasted image	A single reference screenshot	Anything that isn't an inline image

If your requirement is just "customers must be able to attach files to a request", the native Attachments field on the request form is the right answer — no app needed. The rest of this article is for the cases where that stops being enough.

What changed: Forge Object Storage

The reason attachment custom fields existed on Data Center for years but not on Cloud was storage: Cloud apps had no Atlassian-native place to put your files, and shipping them to a vendor's own S3 bucket is a compliance conversation nobody enjoys.

That blocker is gone — Forge Object Storage is finally publicly available (it's no longer a closed, early-access capability in development), which lets Marketplace apps store files inside Atlassian's infrastructure, next to the rest of your Jira data. Full disclosure: we used it to build File Field for Jira & JSM at Terano Apps, and the walkthrough below uses it. The same steps conceptually apply to any field-based attachment app.

Step 1 — Create the field

File Field registers a real Jira custom field type, so this is standard Jira administration:

1. Go to Jira Settings → Work items → Fields.
2. Click Create new field and pick the File Field type.
3. Give it a single-purpose name — Signed Contract, Proof of Identity, Final Asset — and add it to the create, edit, and view screens of the relevant issue types.

Because it's a native field, it then appears everywhere that screen is used: the issue view, the create dialog, workflow transition screens, and the JSM portal form.

Step 2 — Set the upload rules

This is where a dedicated field pays off. Rules live on the field context, so the same field can carry different policies in different projects (… → Contexts and default values → Edit custom field config):

• Allowed file types — pick from PDF, images (PNG/JPEG/GIF/WebP), Word, Excel, CSV, plain text, ZIP, or add a custom type. Leave empty to allow anything.
• Maximum number of files — default is 1 (one field = one document); raise it for multi-file use cases. The limit is cumulative, counting files already attached.
• Maximum file size — default 100 MB; configurable in B/KB/MB/GB. (The Atlassian platform itself caps single files at just under 1 GB — no app can raise that.)

Rules are validated before upload, so users get an immediate, specific error instead of a failed save.

Step 3 — Make the document mandatory (no scripts)

On Data Center this used to be the "ScriptRunner validator" part of the story. On Cloud with a real field it's just Jira: open Field configurations, find the field, click Required. Jira then shows the asterisk on the create screen and refuses to save, edit, or transition the issue until at least one file is attached — exactly like any other required field.

Step 4 — Put it on the JSM portal

Add the field to the request type's form like any custom field — no portal-specific configuration. Customers get the same drop zone on the portal, the same upload rules apply, and when an agent opens the request, the customer's files are sitting in the same named field with download/delete actions.

Step 5 — Search it in JQL (the part attachments never could do)

A file field becomes genuinely useful when you can query it. Each File Field exposes four JQL dimensions:

"Signed Contract".FileCount = 0          — issues missing the document
"Signed Contract".FileType = "PDF"       — by broad type family
"Signed Contract".FileName ~ "invoice"   — by words in the file name
"Signed Contract".Categories = "ID scan" — by admin-defined category label

FileCount is always populated (0 when empty), which makes "missing evidence" audits a one-liner:

project = COMP AND statusCategory != Done AND "Signed Contract".FileCount = 0

These work in saved filters, boards, dashboards — and as JQL conditions in Automation. A common rule: when an issue transitions to Done with FileCount = 0, re-open it or notify the owner.

Where do the files actually live?

The question every security review asks first. With Forge Object Storage:

• Files are stored on Atlassian's own infrastructure, in the same cloud boundary as your issues — no vendor bucket, no external processor to add to your records.
• Every upload, download, and delete is authorized against the user's live Jira permissions (Edit Issue to attach/delete, Browse Project to download). No parallel permission model to audit.
• Access is fail-closed: if a permission check can't complete, the action is blocked.

Typical use cases

• JSM intake — an ID scan or proof of purchase collected as its own required field on the portal, instead of fishing it out of the attachments pile.
• Approvals and compliance — a Signed Contract field that must be filled before the workflow can move on, and a JQL filter that lists every issue where it's missing.
• Creative and marketing work — a Final Asset field so the approved version is never confused with the seven drafts attached along the way.

Try it

File Field for Jira & JSM is available on the Atlassian Marketplace:

→ File Field – Attachment Custom Field for Jira & JSM

Questions about a specific setup — required fields on transitions, portal behavior, JQL edge cases — are welcome in the comments.

Michał Krysiuk, Terano Apps

[William Dorsey]

Finally someone made this — I’ve been waiting so long for this feature