How to Make an Attachment Mandatory in Jira Cloud

File Field — the native attachment custom field for Jira & JSM

Every intake process has one file it can't live without — the signed contract, the ID scan, the log bundle that actually explains the incident. Jira gives files a place to land, but no way to insist on one: the attachments section takes whatever arrives, including nothing at all. Admins have been asking how to change that for the better part of a decade, and the honest answer is a map, not a switch.

A question with a long beard​

People have been asking some version of "how do I make an attachment mandatory in Jira?" on the Atlassian Community since at least 2018, and the question keeps coming back because it arrives in three different shapes:

• On create — a bug report shouldn't exist without a screenshot of the defect.
• On a transition — nothing moves to Done until the signed contract is on the work item.
• On the portal — a service request without the ID scan is just a conversation about sending the ID scan.

Three shapes, one native answer between them. Before reaching for anything else, it's worth knowing exactly where that answer applies — and why it stops where it does. (If you'd rather read this walkthrough where those threads live, we've published a companion version on the Atlassian Community.)

Why Jira can't require an attachment​

Attachments in Jira aren't a field. They're a separate subsystem for files linked to a work item, with a UI that happens to sit among fields — the same design that, back in 2004, led Atlassian to close the request for an attachment custom field as Won't Fix.

Being "not a field" has a very specific cost here. Jira has two mechanisms for making something mandatory: the Required flag in field configurations, and the Field Required Validator on workflow transitions. Both operate on fields, so the attachments section qualifies for neither. The option isn't hidden behind a permission or an admin toggle. It genuinely isn't there.

What native Jira Cloud can do​

The JSM portal: yes, with an asterisk​

The one real native lever lives in Jira Service Management. In Project settings → Request types, put the Attachments field on the request form and mark it Required — from then on, customers can't send that request without at least one file. If "customers must attach something" is your whole requirement, stop here; no app improves on free.

The asterisk: it's portal-only, and something is the operative word. Any type, any size, one file or twenty — the form can't name the document it's waiting for, and whatever arrives joins the shared attachments pile along with the screenshots and the email signatures.

JSM forms: the same promise, the same pile​

Forms attached to a request type can include an attachment question and mark it required. Same enforcement, same scope — plus two caveats of their own: forms shared publicly (without login) can't accept uploads at all, and files submitted through a form still land in the general attachments list, not anywhere a rule could later address.

Workflow transitions: the validator that can't see attachments​

Company-managed workflows ship a native Field Required Validator — "field must not be empty during the transition". It reads like the exact tool for "no Done without the contract", until you open its field list: fields only, and attachments aren't one. This is the point where a decade of Community threads ends with "you'll need an app".

Automation: a very polite guard​

The last native tool works after the fact. A rule can check {{issue.attachments.size}} on a transition and, finding zero, send the work item back with a comment. Real and worth having — but it's detection, not prevention. The save already happened, and the enforcement mechanism is somebody's inbox.

The scorecard:

Turn the file into a field​

Read the failure again and the fix writes itself: attachments can't be required because they aren't a field — so keep the document in something that is one.

File Field registers a real Jira custom field that holds files. That single fact does all the work in this article: a real field appears in field configurations, so Required applies; it sits on create, edit, and transition screens, so the rule holds everywhere those screens are used; and it goes onto JSM request forms, so the portal enforces it too. What follows is ordinary Jira administration.

1

Create a field for the document

Go to Jira Settings → Work items → Fields and create a field of the File Field type. Name it for its purpose — Signed Contract, Proof of Identity, Onboarding Documents — and add it to the create, edit, and view screens of the relevant work item types. One document with its own rules = one field. (The end-to-end setup lives in the docs.)

2

Flip Required in the field configuration

Open Jira Settings → Work items → Field configurations, find the field, choose Required — and that's the entire configuration, documented here.

From here Jira enforces it like any mandatory field: the asterisk on the form, and a create, edit, or transition that would leave the field empty refused with a specific message until a file lands.

3

Put it on the portal

Add the field to the request type's form like any custom field — customers get the same drop zone, and the required rule travels with it. Sending the request with the field empty stops at the form, with Jira's own message: "Please provide a value for required field 'Signed Contract'". When the agent opens the request, the document is sitting in its named field, not fished out of the pile. Details in Use on the JSM portal.

4

Make required mean the right file

Required guarantees a file exists; upload rules decide which file counts. Allowed types, maximum number of files (default is one — one field, one document), maximum size — validated before upload, so the user gets an immediate, specific error rather than a failed save. Rules live on the field's context, so the same field can be strict in Legal and relaxed in Marketing. Together with the Required flag, "one PDF, at most 10 MB, and it must be present" becomes something Jira enforces on your behalf.

Audit the gate​

Every gate has a backlog problem: work items created before the rule existed, bulk imports, a project the field's context didn't reach yet. Native JQL can't surface them — it has no way to ask whether a work item carries a file. A File Field can, because FileCount is populated on every work item (0 when the field is empty):

project = HR AND statusCategory != Done AND "Onboarding Documents".FileCount = 0

Saved as a filter, that's an audit dashboard. Used as a JQL condition in Automation, it upgrades the "polite guard" from earlier — pointed at the one document that matters instead of "any attachment". The pattern, with more queries, is in Find Jira Issues Missing an Attachment, Now with JQL.

Where teams use it​

• JSM intake — an ID scan or proof of purchase the request literally cannot be raised without.
• Approvals and compliance — a Signed Contract gate before work moves on, plus a saved filter that hands auditors the exceptions list.
• HR onboarding — an Onboarding Documents field that must be filled before day one, restricted to the formats HR actually accepts.

Frequently asked questions​

Can you make an attachment mandatory in Jira Cloud? Natively in one place: the JSM portal, by marking the Attachments field (or a form question) required on the request form. There's no native way to require attachments on create screens or workflow transitions, because attachments aren't a field. A file custom field is — which puts Jira's own Required flag back in play everywhere.

Can a workflow transition require an attachment? Not natively — the Field Required Validator's list contains fields, and attachments don't appear in it. With a required File Field, a transition that would leave the field empty is refused by Jira's standard mechanism, no scripting involved.

Can an attachment be required in one project but optional in another? Yes — that's native Jira behaviour once the file lives in a field. The Required flag sits in a field configuration, and each project's field configuration scheme decides which configuration applies, so the same field can be mandatory in Legal and optional everywhere else.

Can you require a specific document, not just "any attachment"? Not with native attachments — the portal rule enforces "at least one file of any kind". A dedicated field per document (Signed Contract, ID scan) makes the requirement specific, and upload rules pin down type, count, and size.

How do you find work items that are missing a required file? Native JQL can't see attachment presence. A File Field exposes "Field name".FileCount = 0, which works in filters, dashboards, and as a JQL condition in Automation rules.