Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Announcing the ability to re-use global custom fields in team-managed projects

Hello Jira Cloud Admins,

We are pleased to share that we will be soon releasing the ability for you to re-use global custom fields in your team-managed projects. Watch out for this feature early in 2023.

Team-managed projects, as its name suggests, empowers teams to configure their own projects to suit how they work. With this new feature, project admins now have the ability to re-use custom fields that are provided and managed by their Jira admins, saving them time to keep field configuration in sync across projects.

Furthermore, downstream applications, like Automation or other reporting processes will no longer require additional data cleansing or logic to merge duplicate fields across projects.


What does it look like?

Search for and reuse custom fields in team-managed projects


Fields previously created in the project are still available and marked with the project avatar


Only fields that have global context are available.

To check, add, or edit a global context: Go to Settings (Cog icon) > Issues > Custom fields, and select Contexts for the field


You can set a global context by going to Create, edit or delete contexts > Edit context > Select the radio button for Global context.


For global fields added to an Issue type of a Team-managed project, you’ll be able to set the default value for the field, but not the Name, Description, or Options (where applicable)


All third-party app fields will now be available by default

This replaces the functionality of the App fields page. We will be removing this page in the future.


Frequently asked questions

  1. What about the existing fields created in team-managed projects?
    There are no changes to these fields. They will not show up in any other projects.

  2. Will there be a way to add a field to all my team-managed projects in one go?
    For now, you will have to add fields to each team-managed projects individually.

  3. Will fields from apps be supported?
    Yes. You will be able to re-use fields and field types from apps.

  4. Will I be able to move my data from existing fields?
    If you prefer to consolidate data in the existing fields, you can move the data using Jira automation.

  5. Will my existing automation rules be impacted?
    No, existing automation rules will not be impacted.
    Additionally, global custom fields will now be available for use in Automation for team-managed projects

  6. Is it possible to try out this feature before General Availability?
    Yes, we are running an early-access program for this feature - please sign up by filling up this survey and we will be in touch.

  7. Will it be available for all Jira Products?
    At this stage we have it working for Jira Software and Jira Work Management. Jira Service Management projects are a little different and we are working towards supporting it as soon as possible.

Feel free to comment any questions and let us know what you think.



Jira Cloud PM


This is great. Thanks for the article @Carol Low 

Like Carol Low likes this

This new feature may be useful and make it less complex to convert team-managed to company-managed in the context of migration.

@Carol Low, for FAQ #4, can you be more specific on how to move data using Jira Automation? The link you provided directs us to a generic page.

Thank you.

Like # people like this

Hi @Carol Low

This is fantastic news! Couple of questions and thoughts:

  • We (and I suspect a lot others) now have a pretty big job ahead of consolidating all of these team managed fields and replacing them with instance-wide equivalents. This specific process (replacing a team managed project field with an equivalent company managed one, moving all of the data, and updating all of the filters, dashboards, and automation rules) is also likely going to live as long as people make team-managed projects. Are there plans to build a migration tool to support this? If not, how can I change your mind?
  • We are in the early access but have not used it outside of testing because we figured it could be removed and\or see major changes before release. Is it safe to begin using this holistically?
  • I absolutely love that the TMP-fields are marked in the field list as being so, but this problem exists anywhere and everywhere you can get a list of fields. For example, if you have multiple "Jira Software" projects you're going to end up with a lot of fields called "Story Points" and "Story Points Estimate", which is really annoying when working with dashboards and Automation rules. Do you have plans to bring this notation into the rest of the application?
  • I totally understand that you can only 5lb of flour in a 5lb bag, time\dev resources\scope are finite, etc. etc. ad nauseum. That being said, the differentiation in functionality between the different Jira products is a distraction and a frustration. If the products are drifting such that you cannot keep them in sync, then either that needs to be addressed or the products need to be forked more deliberately to reinforce that these are different apps. The cognitive dissonance of all of these being "Jira" but also somehow "not Jira" is driving end-users nuts.
Like Carol Low likes this
Carol Low Atlassian Team Dec 06, 2022

@Marini Marini - I intend to write another article with more details, but I've had success (and some others on the EAP) moving fields by setting up a scheduled automation to copy values from one field to another using the "Edit issue" action.


You'll have to wait for the scheduled time for the automation to run, and I recommend testing it out on a small subset of issues first. Make sure you uncheck "Only issue issues that have changed since the last time this rule executed" if you want to update all the issues in the project.

Since this copies the data, it doesn't remove the values from the old field, but you can also run a similar automation to remove the values from the field if that is desired.

Hope this helps!

Like # people like this

@Haddon Fisher - Thanks for your comments - love your continued engagement!

Are there plans to build a migration tool to support this? If not, how can I change your mind?

There isn't a plan for a migration tool right now - but we are considering one that would allow admins to "convert" a team-managed field to a global field. It's not quite the same as a tool to merge fields - that probably has useful applications beyond consolidating team and company-managed fields, but as you can imagine, the surface area is very wide and we have to balance the need of this alongside other things in this domain that are high priority (for example, Priorities per project, multiple contexts per project).

Is it safe to begin using this holistically?

The feedback we have gotten so far makes us confident in the shape we have it. We don't intend to make any major changes.

We do have a few planned changes to reflect team-managed projects in custom fields list is planned. Some of our other customers have began using it holistically.

Do you have plans to bring this notation into the rest of the application?

This is great feedback. Jira fields like Story Points, Story Points estimate should not be showing up in duplicates, if you have any examples of this - could you please share it with us? Preferably in the EAP community group or via email, in case of private information. 

With Automation and Filters (that also power dashboards), fields created in team-managed projects with the same name and field type already appear only once and the data is displayed as a single column. I've run through a few scenarios and there are a few instances where it is inconvenient without temporarily renaming fields, we will look into this.

If you have specific examples of where you are running into issues with the repeated fields, please share them with us.

That being said, the differentiation in functionality between the different Jira products is a distraction and a frustration.

Referring to JSM's team-managed projects - this is something we are actively working on, and if all goes well we will be launching the same time as Jira Software and Jira Work Management. We decided not to hold the feature back for a single project type, and I wanted to provide this information openly. Our plan is to have it ready as soon as we can!

More generally, Jira Software, Jira Service Management, and Jira Work Management (and Jira Product Discovery, which is in our Point A / Alpha program) are separate products with different features. They do share a lot of the configuration as their core. I am very keen to understand how you and our other admins are leveraging shared configuration across the Jira products, to help us make the lines clearer for everyone - I'll reach out again in the new year for this topic.

Like Dave Liao likes this

Hi @Carol Low,

1. I must admit I find that very disappointing. Again, understand that you have a finite number of resources and an infinite amount of work and I absolutely do not want to be a Debbie Downer. And also, I am not seeing any real value in being able to "promote" a field. Maybe I'm the only one, but I'm having a hard time envisioning a scenario where this would even be a thing. However, human error is always a thing, and team-managed project admins will be making fields with the same name and purpose as instance-wide ones on the regular.

2. Awesome!!!!!

3. It does feel like some work occurred here because it feels like I am seeing this less in certain places, but it definitely is still a problem; I will send over examples. However at the end of the day I still think this 'flagging' is necessary. While I agree it probably makes sense to flatten all of the "story points" fields into one, I don't know if you can assume the same for all team-managed project fields of the same name, and they will absolutely exist.

4. I hear you that Atlassian thinks of them as different products; I suppose what I am saying is that I am not sure anyone else does, or if they do, that they want to :) And to be clear, I'm less talking about shared configurations, but more features and functionality:

  • Approval is restricted to JSM
  • SLA is restricted to JSM
  • Forms are restricted to JWM
  • Fully functional Agile boards are restricted to JSW

Why would a Software team not want SLA's? Why wold a business team not need workflow-based approvals? I could also introduce you to a great many business and software teams who would LOVE a portalesque issue creation process (even if you needed a Jira licence to use it).

Like # people like this
Paul Pasler Marketplace Partner Jan 20, 2023

I can confirm, that the feature works in EAP (Developer Canary Program). Nice work!

Can't wait to see it live :)

Like Carol Low likes this
John Funk Community Leader Jan 24, 2023

This is great progress for Team-managed projects!! Not having global access to custom fields was one of the biggest (maybe biggest) complaint I have seen (and used!) against Team-managed projects. There are some exciting fixes like this that are helping with that. 

Like Carol Low likes this


Log in or Sign up to comment

Atlassian Community Events