Why you can't find fields for your JSM forms — and the sneaky new step Atlassian added

[#1]

If you've ever stared at your JSM form editor wondering why a field you know exists just won't show up — you're not alone. There's a checklist most of us have memorized, but Atlassian quietly added a fourth step that's tripping people up.

The classic 3-step checklist

Before blaming the platform (though, spoiler: it might deserve some blame), run through these three. They cover 90% of "missing field" cases:

• Does the field exist in your instance? Go to Project settings → Fields and confirm the field was actually created. Custom fields don't appear globally until they've been added to your Jira admin field list first.
• Is the field added to your screen? Fields need to be explicitly added to the relevant screen (Create, Edit, View). Even if a field exists, it won't surface in forms if it's not wired to the right screen configuration.
• Does the field have the proper context? Contexts control which projects and issue types a field applies to. If the context doesn't include your project or issue type, the field is invisible to your form — even if it's on the screen.

Go through all three? Field still not showing up? Welcome to the club. There's a new wrinkle.

---

The fourth step nobody told you about

I was deep into an ITSM implementation with a client — standing up a fresh JSM project, configuring request types, building out forms — when I hit a wall. Fields I'd confirmed were real, screened, and contexted correctly just refused to appear as options in the form editor.

After digging around, I found it: you now have to explicitly add fields to the field configuration as well. This is a separate step from adding a field to a screen — it lives in the field configuration scheme associated with your project, and it controls whether a field is active, required, or hidden at a scheme level.

This step used to happen automatically. Fields were included by default, and the field configuration scheme was mostly something you'd only touch if you needed to make a field required or hide it. Now? You have to go in and manually activate fields before they'll show up as options in your form builder.

⚠ New in recent JSM versions

If your fields exist, are on the right screen, and have a matching context — but still won't appear in your form — check Project settings → Fields → Field configurations. The field may need to be explicitly enabled in the active field configuration before it becomes selectable.

What is Atlassian thinking?

Honestly? I'm not sure this was the right call. Field configurations have always been one of the more confusing corners of Jira's admin model — most admins treat them as a "set it and forget it" layer. Turning them into an active gating mechanism for form fields adds real cognitive overhead, especially when you're onboarding new projects or doing rapid ITSM builds.

The old behavior — auto-include fields, let admins opt out — was more intuitive. Discovery by absence is a terrible UX pattern. Nobody looks at an empty form field picker and immediately thinks "oh, I must need to check my field configuration scheme." They think the field is broken.

If this is intentional architecture to give admins more granular control, fine — but then it needs clearer documentation and better error messaging in the UI. Right now it's a silent failure that costs time.

---

Updated checklist (save this)

• Field exists in the instance
• Field is added to the relevant screen
• Field has the correct context (project + issue type)
• Field is enabled in the field configuration for your project — Project settings → Fields → Field configurations

Has anyone else run into this? Is this a recent change or has it been there longer than I think? Drop your experience in the comments.