How to you identify a Point of Contact like a Project Manger on a Jira task?

vildana_ermaya

Curious how others identify who a Point of Contact is on a Jira issue. Do you use a custom field or are there other options?

We're exploring this option since a reporter on an issue may or may not be the actual Point of Contact for all questions someone like a Dev might have about the issue.

Thanks in advance! 

Mykenna Cepek

A custom field is the usual approach.

If the Point of Contact will always be someone who is a user in your Jira instance, then that new custom field would be a User Picker, and it's all pretty straightforward. Hopefully this is your situation.

If you have Points of Contact who are not users in your Jira instance, then it gets more complicated. You might want the contact name, their email, perhaps their title, etc. So a multiline text custom field seems like it might work. However:

• Not using a User Picker for an internal Point of Contact means people would be manually entering emails, which might be typed incorrectly.
• Having name and email and maybe other information in a bulk text field makes it inconsistently formatted -- useful for humans, but not for any other automation or other types of usage.

The usual next type of approach is multiple fields: Name and Email at least, both single line text fields. If you want to get fancy, the email field can do some validation for a valid email address (that's not fun); but if you don't, emails might be invalid.

One other (rather horrible) option is a Single Choice Select List. This might work if you have a known, small, and rarely changing set of Point of Contact persons. Then at least it's easy for people to pick them out of a fixed list, and have it be consistent -- perhaps even in "First Last"<email@addr.ess> format. But maintaining the values in that custom field can be quite some overhead.

A final option is to use something from the Atlassian Marketplace to bring in data from an external system, to offer as choices for a Point of Contact field. If you've got some CRM data, you could use that; perhaps even mix it with internal employees to have both internal and external people on offer.

Of course, more than a few score becomes unusable from a UI/UX perspective -- the list of options is just too long. You'll find yourself wishing for a rather complex field that can look up contacts with partial searches, or even offer multi-level lists within the field. This approach requires some non-trivial technical effort for the integration.

Further suggestions, anyone?