What is the best practice for custom field contexts?

[Michael Brändel]

When I create a new custom field, Jira automatically creates a default global context for that field (all issue types, all projects). 

Does this have any negative impact (performance) on the Jira instance? 

One negative effect I observed is that whenever you need to bulk-change issues, you find yourself scrolling over an extensive list of fields, even if they are not used in the projects. 

Would it make sense to keep the global context only for fields when they are used by many projects, and for specific custom fields that are used in a few projects only, keep the context closed to the respective issuetypes/projects? 

Any recommendation is highly appreciated. 

[Mohamed Benziane]

Hi,

I usually avoid using a global context for custom fields.

Using contexts allows you to use one field with different values in different projects, so you don’t need to create almost the same custom field many times. I think only system fields should have a global context (this is the default behavior and cannot be changed). All custom fields should have a specific context instead.

On Data Center, Atlassian recommends not using global context because it can cause performance issues.Configuring custom field contexts | Administering Jira applications Data Center 11.0 | Atlassian Documentation

[Michael Brändel]

Thank you @Mohamed Benziane .

Besides different values in different projects, I understood that the context also determines whether a field is available in a project at all. For example, if I create a text field, it will be available in all projects for all issuetypes by default. So each issue of any project will have that field, despite not really using it because it is in none of the screens. 

If this impacts the performance of the instance, I think the default context should probably be limited, either to projects and/or to issuetypes, right? 

On the other hand, this will probably lead to more maintenance effort if many projects share their configuration. At our company, we utilize template projects with a predefined configuration. 
Therefore, every time a new project is created using that shared configuration, you would need to add that project for all field contexts.  That is also not a sustainable solution in my view... 

I guess the better approach for this use case would be to have a Field Configuration Scheme for each of the shared project templates and hide all fields that are not applicable to those projects. Does this make sense?