How to make an attachment mandatory in Jira Cloud (Jira & JSM)

[#1]

Require a photo of the defect before a bug can be raised. Block the Done transition until the signed contract is on the work item. Make a service request impossible to submit without an ID scan. Some version of this question has been asked on this Community every few months since at least 2018 — and the native answer has barely moved in all that time.

This article maps the territory as it stands in 2026: what Jira Cloud can enforce natively, where each option stops, and how to get a real "no file, no save" rule — on the create screen, on workflow transitions, and on the JSM portal.

Native attachments accept an empty save; a required File Field refuses it.

Why "just make it required" doesn't work

Attachments in Jira aren't a field. They're a separate subsystem for files linked to a work item — and both of the mechanisms Jira uses to make anything mandatory, the Required flag in field configurations and the Field Required Validator on workflow transitions, operate on fields. The attachments section doesn't qualify for either, so the option simply isn't there to click. (The history of why — including the original 2004 feature request that was closed Won't Fix — is in our previous article, How to add an attachment custom field in Jira Cloud.)

That leads to a starting point worth stating plainly: as of 2026, there is exactly one surface in Jira Cloud where native attachments can be made mandatory — the JSM portal. Everywhere else needs a different approach. Let's take the options in turn.

What you can do natively

JSM: a required attachment on the request form

Open Project settings → Request types, pick the request type, and mark the Attachments field as Required on the request form. From then on, a customer can't submit that request from the portal without attaching at least one file. If your requirement ends at "customers must attach something", this is the answer — no app needed.

Two limits to know about. It's portal-only: the request form and its required flag don't apply when someone raises the same work item type from inside Jira. And "at least one file" is the entire rule — any type, any size, one file or twenty. The form can't say which document it's waiting for, and whatever arrives lands in the general attachments list along with everything else.

JSM Forms: a required attachment question

If your intake runs on forms, a form can include an attachment question and mark it required — same enforcement, same scope. Two caveats here as well: forms shared publicly (no login) can't accept file uploads at all, and files submitted through a form still end up in the work item's shared attachments pile, not in a field you can point a rule at later.

Workflows: the validator that can't see attachments

Company-managed workflows do ship a native Field Required Validator — "field must not be empty during the transition". It sounds like exactly the tool for "no Done without the contract". But its list contains fields, attachments aren't one, and so they never appear in it. "Don't allow this transition until a file is attached" is not something native Jira Cloud can express — this is the point where Community threads traditionally end with "you'll need an app", and workflow-extension apps have shipped attachment validators for years to fill exactly this gap.

Automation: detection, not prevention

The last native tool is a rule that reacts after the fact: check {{issue.attachments.size}} when a work item transitions, and if it's zero — transition it back, comment, ping the assignee. This is real and worth having. Just be clear about what it is: cleanup, not a gate. The save already went through; the rule is chasing it, and somebody's inbox is the enforcement mechanism.

The scorecard so far:

Where you need the rule	Native option	What it actually enforces
JSM portal request	Required attachment on the request form, or a required form question	Some file — any type, any size
Jira create screen	—	Nothing
Workflow transition	— (the validator can't target attachments)	Nothing
After the fact	Automation rule on {{issue.attachments.size}}	Detection, not prevention

The short version of this article: where each approach can — and can't — enforce a file.

The field-based approach

If attachments can't be required because they aren't a field, the fix follows directly: keep the file in something that is one. Full disclosure: we build File Field for Jira & JSM at Terano Apps, and the steps below use it. It registers a real Jira custom field that holds files — which is precisely what makes everything below ordinary Jira administration rather than app configuration.

Step 1 — Create a field for the document

Go to Jira Settings → Work items → Fields, create a new field of the File Field type, and name it for its purpose: Signed Contract, Proof of Identity, Onboarding Documents. Add it to the create, edit, and view screens of the relevant work item types. One document with its own rules = one field. (The full setup walkthrough — upload rules, JQL, where files are stored — is in the previous article.)

Step 2 — Flip Required in the field configuration

Now the part that native attachments can't do. Open Jira Settings → Work items → Field configurations, find the field, and choose Required. That's the entire configuration — there's nothing else to set up.

The Required toggle in Jira's field configuration — the same switch every other mandatory field uses.

From here Jira treats the field like any other mandatory one. The asterisk appears next to the field name, and a create, edit, or transition that would leave the field empty is refused with a specific message until at least one file is attached. On the create dialog, that moment looks like this:

The create dialog refuses to save — "Onboarding Documents is required" — until a file lands in the field.

Step 3 — The same rule follows the field to the portal

Add the field to the request type's form like any custom field. Customers get the same drop zone on the portal — and the required rule holds there too. Trying to send the request with the field still empty is stopped at the form, with Jira's own validation message: "Please provide a value for required field 'Signed Contract'". When an agent opens the request, the file is sitting in the named field — not fished out of a pile of screenshots and email signatures.

The JSM portal blocks Send with Jira's own validation message until the document is attached.

Step 4 — Make "required" mean "the right file"

"Required" guarantees a file exists. Upload rules decide which file counts: allowed types, maximum number of files (the default is one — one field, one document), and maximum size, all validated before upload so the user gets an immediate, specific error instead of a failed save. Rules live on the field context, so the same field can be strict in the Legal project and looser in Marketing. Put together, "one PDF, at most 10 MB, and it must be present" becomes a sentence Jira can enforce on your behalf.

Upload rules on the field's context: which types are allowed, how many files, and how large.

Audit the gate: find what slipped through

Every gate has a backlog problem: work items created before the rule existed, bulk imports, a project the field's context didn't cover yet. Native JQL can't help here — it has no way to ask "does this work item have a file?". A file field can, because each one exposes its state to JQL and FileCount is always populated (0 when empty):

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

Save it as a filter and the audit becomes a dashboard gadget. Use it as a JQL condition in Automation and you get the reactive rule from earlier — but pointed at the one document that matters instead of "any attachment", which turns "detection, not prevention" into a follow-up process you can actually run.

The same FileCount check, used as a JQL condition inside an Automation rule.

Where this lands in practice

• JSM intake — an ID scan or proof of purchase that must be attached before the request can be raised, collected as its own field instead of "please attach it, thanks".
• Approvals and compliance — a Signed Contract that has to be present before work moves on, and a saved filter that shows auditors every work item where it's missing.
• HR onboarding — an Onboarding Documents field that must be filled before day one, with the file types and size limits HR actually accepts.

Quick answers

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

Can a workflow transition require an attachment?
Not natively — the Field Required Validator can't target attachments. With a file custom field it's the standard mechanism: the field is required, so a transition that would leave it empty is blocked.

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 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 an Automation condition.

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 behaviour, retrofitting a process that already has thousands of work items — are welcome in the comments.