Jira Product Discovery - Naming Standard Recommendations?
Asked by Gail:

I am the administrator for all Atlassian products. I keep documentation on things like a list of our custom fields, statuses, etc. and I am wondering if anyone has run into issues with JPD fields being named the same as a Jira Software field? I would love to know how you solved the problem of naming standards.

My thought was to prefix or suffix the field name with **JPD** or something similar. Once JPD goes GA, I need to have some standards in place so I don't go nuts trying to figure out why we have what looks like duplicate field names.

Thanks.


Answers:
author: Chris Timms
body: Hello [@Gail](/t5/user/viewprofilepage/user-id/4554905)

I am not sure JPD (or generally, team managed projects) are compatible with a requirement to maintain a list of all custom fields separate to the project those fields make sense in.

JPD makes it really easy to create and maintain new fields per project.You can find more information on the difference between team and company projects [here](https://support.atlassian.com/jira-software-cloud/docs/what-are-team-managed-and-company-managed-projects/) but it seems like team managed projects are resistant to central management and documentation like what you describe by design.

Regards,

-C

comments: author: Gail
body: Thanks Chris.

To clarify more - i wasn't looking to document team-managed/JPD objects. I pulled an API call to get a list of all our custom fields. When I reviewed it, I happened to see a duplicate named field **effort**. I only knew of one field used for our company-managed projects. In more digging I found 20 JPD fields listed. I don't really care that they show on this list, but what I am concerned with is when they use the same name as existing objects.

These duplicate fields can be seen/used in filters, so this will be confusing to users.

I was just wondering if I needed to come up with a JPD special naming pattern before we go GA. This was totally unexpected.

![jpdfields3.png](https://community.atlassian.com/t5/image/serverpage/image-id/257825i44444A0BAD289D14/image-size/large?v=v2&px=999 "jpdfields3.png")


author: Chris Timms
body: [@Gail](/t5/user/viewprofilepage/user-id/1379976) makes sense - thanks for the reply!

JPD is going to spin up those 'default' fields any time you create a new JPD project, so if you can keep pace with the maintenance then a JPD-specific prefix is the only way I can think of that will solve for field ambiguity caused by creating a JPD project. This will be the case anytime someone creates a new team-managed project in your instance, though. Hopefully that's not happening too often :D

Regards,

-C


author: Gail
body: thanks. Luckily I am the only one allowed to create projects so I can at least keep a list of the "culprits" lol.


author: Rabbit Stoddard
body: I'd honestly prefer they don't show unless they're company managed project fields, myself.


author: Rohan Swami
body: [@Gail](/t5/user/viewprofilepage/user-id/4554905) [@Chris Timms](/t5/user/viewprofilepage/user-id/1260719) you're exactly right in the way JPD fields are created. Thanks for sharing your use case here, I was unaware customers were reviewing JPD fields through APIs!

comments: author: Gail
body: Thanks Rohan. That is the only way I am aware of in Cloud to get a full custom field listing without copying and pasting. It was suggested to me by Atlassian Support. If there is a better way, I would love to know.