Should I create one custom field per project or one custom field at the account level?

[Domi]

Hi Atlassian community,

We have created 1 custom field in 2 different projects in our Jira account. These 2 custom fields have the exact same name and exact same value options.

We will be creating a filter for a dashboard using these 2 custom fields.

Now my question is: when we start reporting on the project status, will the data get messy because there's a repetition of the values i.e. there are two versions of "On Track"? Shouldn't we be creating a custom field at the account level and this 1 custom field can be used across the 2 projects?

Thanks for your insight and recommendations.

Domi

[Clark Everson]

Hi @Domi 

It's better to do as much as possible from account level. This simplifies management of the tool long term as well as makes it easier for users to search for like data.

Best,

Clark

[Marlene Kegel - codefortynine]

Hi @Domi,

I am Marlene, product manager of Quick Filters for Jira Dashboards.

If you get in a situation that you have to work with two different fields per project, you can also try out our app. We provide a set of dashboard gadets that match fields per name, not per ID. Therefore it's possible to group them when displaying them on your dashboard. 

[Mit Tolia]

Hi @Domi

I'd agree with Clark's comments above. It is always desirable to ensure you are not ending up creating duplicate fields (especially the one that you have shared in the question above) which are specific to Jira projects, as it could get messy very quickly and will create a lot of admin over head to manage those duplicate fields.

I have seen what really works is looking at the custom field and understanding what aspects of the business process, it is aimed at addressing? Is it required by all departments/business areas to drive consistent reporting and ensuring various departments are able to use the same common language/taxonomy? Will the field be used to report onto for leadership reporting (usually a consolidation of multiple team's data that could be spread across multiple Jira projects)?

Additionally, If you wanted to run automations on the fields or use the field to drive APIs etc. you'd prefer to work with a single custom field across the instance to avoid additional complexity around extracting field ids etc.

If there was a genuine use case where, lets say, the option values for a single list custom field are very specific to an area of business (potentially will have a bunch of Jira projects) compared to another business area - there is an option/functionality to set "contexts" for the custom fields which allows you to select a set of projects that shows a specific set of options without having to create duplicate custom fields; however I would recommend that you use this functionality only when it is absolutely needed and it also requires an immense care that needs to be taken as managing fields with contexts can get tricky and is risky (if they are not managed properly, it can result in a lot of complexities that requires clean-up etc) - Hence the suggestion that whilst this option exists, use it only as an exception & with extreme caution.

Overall, I'd still say & suggest, stick to one custom field across your Jira instance/site

Hope this helps.

Thanks and Regards,

Mit Tolia