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

[#1]

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.

Regards

Carol

Jira Cloud PM

[Yatish Madhav]

This is great. Thanks for the article @Carol Low 

[Marini Marini]

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.

[Haddon Fisher]

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.

[Carol Low]

@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!

[Carol Low]

@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.

[Haddon Fisher]

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).

[Paul Pasler]

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

Can't wait to see it live :)

[John Funk]

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. 

[Patricia Francezi]

Hi @Carol Low 

Is this just available for EAP yet?

[Carol Low]

Hi @Patricia Francezi !

This is now generally available for all Jira Software and Jira Work Management projects.

If you are keen to have Early Access for Jira Service Management, please fill in the form in the original post and we will add you to the list. The EAP for JSM should begin shortly.

[Majken Longlade]

This breaks the instructions for migrating from a team-managed project to a company-managed project. It looks like now the global fields need to be added to the team-managed project and the data needs to be copied from one field to the other before moving the issues to the new project?

Good thing I tested this in a sandbox rather than assuming it still worked like it used to.

[Tomasz Bis]

HI @Carol Low 

Any idea when is it going to be released for Jira Service Management please?

Many Thanks

[David Bakkers]

Will there be updates to the Jira v3 REST API endpoints to allow the creation and editing of these custom fields within Team Managed projects?

[Paul Pasler]

Hi @Carol Low ,

following @David Bakkers question. 

Is it currently possible to create a custom field, provided by a third party (Forge) app, in a team-managed project? Haven't found a way in the UI or any APIs.

If not, are there plans to do so? Is there a Ticket I might vote for or watch?

Thanks in advance!

paul

[Garrett S]

Is there any ETA on when this will be released for team managed JSM projects?

[Carol Low]

Hi everyone,

Sorry for the delay as I've been out of office.

@Tomasz Bis @Garrett S  We are getting ready to release this for JSM end of the month/early July if everything goes well.

@Majken Longlade thanks for bringing it to our attention, we will work on updating that document.

@Paul Pasler At the moment there isn't that I am aware of. Can I understand a bit more about what you would like to do? Feel free to email me at clow@atlassian.com if confidential.

[Nicole Schwartz]

Hey @Majken LongladeI'm helping with the documentation on this.

Let's say you have a custom field created in your team-managed project which is equivalent to a global custom field with a global context and you want to migrate from your team-managed project to a company-managed project which uses that global custom field. Before moving your issues, you will need to first add the global custom field to your team-managed project and move the data from your existing custom field to the global custom field (you can move the data using Jira automation). 

[Haddon Fisher]

Hi @Nicole Schwartz - that process can still be pretty time-intensive particularly when the project has a lot of request types...any chance there is some logic in the works to handle this more directly?

This will ultimately be needed to convert team-managed projects to company-managed ones (which is absolutely a must have), so seems like it's worth the effort.

[Paul Pasler]

Hi @Carol Low,

thanks for taking care of our request :)

By providing custom field support for team-managed projects, you've added the ability to not only assign, but create custom fields for this project in particular. 

At the moment you can only choose a small set of Jira standard custom fields (Short text, Paragraph, etc.). As a app vendor of a custom field app, we would love to create such "project scoped" fields ourselves (see attached screenshot).

To achieve this, we either need a Forge module to get into the UI or at least a REST API to enable project admins to create any of our custom fields.

Hope this was understandable. If you have further questions, do not hesitate to contact me :)

Cheers,

paul

[Carol Low]

@Paul Pasler - here's the feature request ticket as I've mentioned by email - sharing it here for others to vote for and comment :)