nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

How do I let users create their own service desk fields?

red888

I have a couple of service desk projects for a few different teams.

I want teams to be able to create any fields they want to add to their own service desk portal.

Seems like a super basic use case, but I guess its impossible ootb?

The solution is either:

1. Make them all system admins to let them create new fields that ALL service desk projects will see

2. OR bottleneck every single request for a new field through a Jira admins team who must approve them.

There has to be a better way right? It seems crazy I can't support this ootb.

Accepted answers

All comments

Mikael Sandberg

It all depends on what type of project you are. using. If the projects are team-managed then project admins can create fields that they want. But if you are using a company-managed project then you have to be a Jira admin in order to create new fields.

Your other option is to use Forms, that would allow the project admin to create a new form with the fields that they want. This works if you do not have to report or search on the fields in the form.

Trudy P Claspill

Hello @red888

To allow non-Jira Admins to create fields for use in a project they must be using a Team-managed project. In such projects the users assigned to the Administrator role in the project can create custom fields that are isolated to that one project.

For more information about the differences between Team and Company Managed projects refer to:

https://support.atlassian.com/jira-software-cloud/docs/learn-the-basics-of-team-managed-projects/

Note introducing Team Managed projects to your environment can potentially cause other challenges, like multiple custom fields that have the same name but are different per project. That can make filtering difficult for a user who is not sure which field named "X" they need in their filter.

Also, it is not possible to change an existing project from Company Managed to Team Managed. You have to create a new Team Managed project, recreate the configuration to match your Company Managed project (because TM projects don't use the globally managed schemes), and move the issues from the CM project to the TM project. During the move data may be lost from the issues so it is important to test that process very carefully with a limited number of test issues to ensure no data will be lost when "real" issues are moved. More information about this can be found here:

https://support.atlassian.com/jira-software-cloud/docs/migrate-between-team-managed-and-company-managed-projects/

Other than Team Managed projects, if you did not want to give user Jira Admin access then you would need to look for third party apps that could give access to creating Global custom fields without giving access to other Admin functionality.

Andrej Freeze

Hey @red888, I get where this is coming from and on the surface this feels like a super basic need: each team should be able to shape “their” portal and just add the fields they need.

The tricky part is that in Jira Cloud, custom fields and screen configs are truly global configuration. A field created “for one” service project is still a global object that can affect performance, search, reporting, and the experience in other projects.

From my point of view this is one of many reason why field creation and screen changes should remain an admin task. It’s meant to protect the overall system (and other teams) from well‑intentioned but risky local changes and keeps the amount of configuration waste admins needs to take care of a fair bit lower.

There is a workaround in the direction you’re thinking, but it’s very much a “power user / at‑your‑own‑risk” pattern, not an officially supported or recommended feature. The pattern is roughly: create a special JSM request type that only a certain group can use, capture the desired project/request type/field details in that request, and then use automation to trigger a Forge app or integration that runs with admin‑level scopes.

That app can then call the Jira REST APIs to create the custom field and wire it into the appropriate screens and request types behind the scenes. Technically this works, and it can streamline and standardise how fields get created, but it is limited and can cause some disruption.

Still, hope this helped a little

Trudy P Claspill

Hello @Andrej Freeze

You have not mentioned the availability of the solution I specified - Team Managed projects, and yet that provides exactly what the author asked for.

Do you not consider that a viable solution? If not, why not?

Andrej Freeze

Hi @Trudy P Claspill, you’re absolutely right that Team‑managed service projects give exactly what was asked for and that is project‑level control over fields without needing Jira admin.

In my first reply I focused on the company‑managed/global config side of things and on the “power user + automation” pattern, mainly to avoid just repeating the Team‑managed option you had already pointed out including some important caveats coming along.

So yes, just to clarify: Team‑managed is a perfect fit if each team can live with its own config and reporting trade‑offs.

Thanks for raising it. Together the answers give a much more complete picture for anyone reading

Arkadiusz Wroblewski

@red888

You’re not missing anything, this is basically how Jira/JSM is designed.

In company-managed JSM projects, custom fields are global objects. So if you let non-admins create fields, they’re effectively creating fields that can appear across the whole site, which is why Atlassian restricts field creation to Jira admins. That’s also why your two options feel like the only ones.

The “best practice” way to solve this without making everyone a system admin is:

Keep custom field creation under a small admin/governance group (to avoid global field sprawl).

Give teams autonomy where it matters: portal / request type configuration, and Forms.

What I typically recommend:

Use JSM Forms for team-specific portal questions (recommended) Forms are project-scoped and give teams flexibility to add/change questions on their portal without creating new global custom fields. This avoids polluting the instance with hundreds of one-off fields and removes the admin bottleneck for most requests.

Standardize a shared “field catalog” for true structured data Maintain a controlled set of reusable global fields (created by admins) for data you actually need for reporting, automation, SLAs, etc. Teams can still decide which fields show up on which request types.

Only use team-managed projects if you explicitly want decentralized field ownership Team-managed projects allow project admins to create fields that are isolated to that project, but you trade off standardization and some advanced admin/governance capabilities. It can work for smaller orgs or truly independent teams, but it’s usually not the default choice at scale.

What I would avoid is making every team a Jira admin just to create fields: that becomes unmanageable very quickly (security, governance, and “field explosion”).

So: yes, there’s a better way than the two extremes 😉 Forms + controlled global fields, with teams owning their request types/portal configuration.

Olha Yevdokymova_SaaSJet

Hi @red888

In company-managed JSM projects, custom fields are global objects. So allowing teams to create their own fields means they’re creating fields that exist across the entire site. That’s why Atlassian restricts field creation to Jira admins — it’s about performance, governance, and avoiding “field explosion.”

The two extremes you described are indeed the obvious ones:

Make everyone a Jira admin (not realistic long-term)
Centralize all field requests through a governance team

There isn’t a hidden third native toggle.

What actually works in practice

You already got the correct answer regarding Team-managed projects. That’s the only native way to let project admins create fields scoped to just their project.

The middle ground most orgs use

For company-managed environments, the common scalable pattern is:

Keep global custom fields controlled by a small admin group
Let teams control their request types, portal layout, and Forms

This is where JSM Forms become important.

Forms are project-scoped and allow teams to:

Add new questions to their portal
Change structure anytime
Avoid creating new global fields
Stay independent

If teams need even more flexibility

If you want company-managed governance but more flexibility than native Forms allow, some teams use Smart Forms for Jira (built by my team).

Smart Forms:

Are not limited to Jira project
Form fileds can be conncted or not with custom fields
Don’t require creating new global custom fields
Allow teams to add/change form structure freely
Only map fields that needed to Jira if reporting or automation requires it

Smart Forms lets teams create project-level forms that:

Do NOT create global custom fields.
Do NOT require Jira admin permissions.
Do NOT affect other projects.
Do Not need agent licence
Can be edited by project admins.

That means:

Instead of saying:

“We need a new custom field called ‘Environment Type’”

The team can:

Open Smart Forms
Add a new question called “Environment Type”
Add dropdown options
Connect with any field or not connect
You can publish all form answears even to description field and formatting will look like Question: Answear
Publish

red888

I think this is what I want, but I'm not sure how could be used: "Add new questions to their portal"

I want the responses to the portal questions to appear on the Jira issues that are created from the portal in a way that is easily retrievable programmatically.

Is there a way to attach all question/answers to the Jira issue that is created as a json object? And will these question/answer key value pairs attached to the Jira issue be queryable with JQL?

Trudy P Claspill

Hello @red888

To be clear the functionality you say you want, as described by @Olha Yevdokymova_SaaSJet and quoted by you, requires that you subscribe to the Jira Service Management app. That is separate from subscribing to the Jira app, though they can co-exist in the same site/UI. If you are not already subscribed to JSM then that will be an additional licensing cost.

For more information on that licensing cost refer to:

https://www.atlassian.com/collections/service/pricing

red888

@Olha Yevdokymova_SaaSJet @Trudy P Claspill I just wanna confirm something with smart forms. Where do all these smart form questions live on the jira issues that are created? Can this metadata be easily retrieved programmatically?

I want to automate this eventually so can I do the following with smart forms:

User submits a form with all my questions
A jira issue is created and all those question/answer values are present on the Jira issue (I can't store them in "fields" because those are global so where does this info go?)
I can make API calls and or JQL searches on those issues and query with these smart form question/answers data that lives in the jira issues somewhere

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-service-desk-cloud

jira-cloud