Hi everyone,
The most common question I get from project admins is some variant of "I added the field, why can't I see it?" And the honest answer is that there are at least five places it could be dying, in a specific order, and you have to check all of them.
Field context (is the field even scoped to this project and work type) → field configuration (is it hidden) → the screen (is it on the right one for create/edit/view) → the screen scheme and work type screen scheme (is that screen actually associated here) → and now the layout (is it placed in a section, and which one).
Five layers, two different admin roles, and no single page that tells you the answer. The old "Where is my field?" helper answers part of it, but nobody I train remembers it exists.
So why do layouts exist at all?
I think the reasonable answer is that screens were designed for a form. A screen is a membership list plus an order, rendered top to bottom, and that model worked perfectly when creating, editing and viewing were three separate pages that each looked like a form.
The current work item view isn't a form. It's a page with regions — description, a details panel, context, more fields. Screens simply can't express "put this in the sidebar," because position wasn't a concept they were built to carry. Layouts were the answer to that: the docs are explicit that the fields available to you in the layout come from the global screen configuration for viewing the work type. Screens decide whether a field exists here; layouts decide where it lands.
That's a defensible split. The problem is everything around it.
What it costs in practice:
- Ownership is split down the middle. Jira admins own screens and tabs; project admins own layout. So the person who can move a field often can't add it, and the person who can add it isn't the one being asked.
- The blast radius is genuinely unclear. The documentation says layout settings are for individual projects, but there are multiple threads here from admins who changed a layout and got warned it would affect other projects sharing the same screen scheme — and it did. I've seen both behaviours and I still can't state the rule confidently, which is not a great place to be when you're advising a client.
- The layers leak into each other. Add a field in the layout editor and Jira quietly adds it to the underlying screen for you. Remove a field from the edit screen and it can still sit there in the view configuration, visibly present and mysteriously uneditable.
- Hiding in a layout is cosmetic. It's not a permission and not a data control. The field is still there via API, automation and bulk edit. I've had to explain that one in a compliance conversation.
What I'd like to hear from this group:
- Have you settled on a policy — configure everything through screens and treat layout as cosmetic, or lean on layout and let it manage the screen for you?
- For those running many projects that must look identical: how are you keeping layouts in sync? Copy layout gets you the first version and then drift starts on day two.
- Has anyone actually nailed down the shared-screen-scheme behaviour? A definitive answer with a test case would be worth a lot to this forum.
- And the bigger one: if the view is no longer a form, is there still a reason for screens and layouts to be two separate models — or is this a merge waiting to happen?
Thanks,
--Hugo
