JPD Field Restrictions in general & because it is Team Managed and not Company Managed Project

[Wendy Grapentine]

My wish list:

1) I wish JPD would support all the same field types that JIra has.  
    Specifically, JPD does not support any text fields that are longer than short text. 
    Also, JPD does not support radio buttons. 

Reason for my frustration:  We currently have a workflow where all development requests get funneled through Jira Service Management.  At that point, I attach a triage grooming form that gets filled out and is linked to various Jira Fields. 

From this point, I monitor all the incoming JSM requests for completeness and then, using automations, will either send it directly to the Incident and Support Kanban Jira project OR if it is more of a longer term, project request, I then send it over to JPD for further requirements gathering and design etc. 

The longer term Project requests flow looks like this:
1) Request comes in via JSM
2) I assess the request and fill out initial Triage Form in JSM (which is linked to various Jira fields)
3) If the request is related to longer term project that needs more extensive requirements gathering and design, I then run a automation that creates an Idea in Jira Product Discovery and copies over the various Triage fields from JSM. 
4) Then the idea is further vetted, requirements are gathered and design is completed in JPD. 
5) When the idea is ready for Development, I then run an automation that creates an Epic or Story in the Development Project Jira Project and copies over the various fields from the JPD to the final Jira ticket.

Because, JPD does not support radio buttons that I have in the JSM form, I had to adjust those fields to single select dropdowns and then I just display the field contents in the JSM form using radio buttons.  No harm, no foul here, I just wish I had known before hand that JPD only supported checklists or single-select dropdown before I had created the fields to shared initially with JSM and Jira. 

Also, because JPD does not support Description or Paragraph or Long text, I had to adjust the Description and a few other long-text triage form fields from long text to short text which is not necessarily enough space for the answers to those form fields. 

I just wish JPD supported all the field types that JSM and Jira does out of the box so I didn't have to go back and adjust a bunch of fields to fit the JPD.  Especially when the longer field types are needed during requirements gathering etc. And for throughput of JSM form fields through JPD and eventually into Jira. 

2) Also, discovered the JPD does not support the same global Due Date field that is already inside Jira and JSM - that is frustrating. 

3) Finally, I wish there were an option to make JPD company-managed and not just team-managed.  Reason-- Duplication of various fields when looking at all the fields as an Atlassian Admin.  It is also confusing when there are more than one team using JPD.  So currently I have 3 fields named "Effort", 3 fields named "Confidence" etc. 
It just muddies up the Admin space when there are a bunch of duplicated fields in the main fields list. 

There is my two cents. Thank you for coming to my Ted Talk.

[Tanguy Crusson · Accepted solution]

Hi @Wendy Grapentine , thanks for the feedback

On the topic of fields proliferation, JPD supports Global fields today: https://support.atlassian.com/jira-product-discovery/docs/create-and-manage-global-fields/
you define and manage them centrally, then decide the list of spaces you want to add them to. We're currently working on Global views to the same effect. 

[Gary Spross]

"I wish there were an option to make JPD company-managed and not just team-managed."

I so agree with this statement.

[Simon Yu]

We solved this problem. At my organization, we are designing a similar workflow where we are using JSM forms as our intake and using automation to push fields captured on JSM through to JPD into a newly created idea.  Initially we hit the same roadblocks where long text and paragraph cannot be mapped to JSM 1:1 since JPD does not have those field types.  Same challenge with radio button as JPD does not have that field type.

The real constraint is you cannot have a JSM custom field (long paragraph / long text) map to a JPD custom field, of any type.  The way to solve this is to have a JSM custom field map (long paragraph / long text) map to JPD's system level description field.  So under automation, you would specify your smart values within JPD's "Description" field that is out-of-the-box and system level.  If your JSM field has more than 1 paragraph and/or long text field, they will all have to get mapped to the JPD description field - yes, that field can support multiple smart values. 

For example, what we did is we typed out in the JPD description field "1. Detailed Description" and beneath that specified the smart value, and then beneath that typed "2. Current Workaround", and then added another smart value there, and so on.  So what you end up having is multiple paragraphs / long text fields mapping to a single JPD system level description field. So it will look like this:

*1. Detailed Description of Request / Idea:*
{{forms.last.Your_Field_Key_ID1}}

*2. Current Workaround:*
{{forms.last.Your_Field_Key_ID2}}

Note: Your_Field_Key_ID is the custom field key that you specify under form builder for each field.  We also added asterisks at start and end to bold things in the JPD description so that it makes things easier to read.

When it comes to radio button, this just needs to be captured in automation as a single select - basically same way you would capture a dropdown list. 

For example: {{forms.last.Your_Field_Key_ID3.label}}

There is a limitation to be aware of this - if in your JSM form builder you are using the Add 'Other' option where if Other option is selected, it dynamically creates a free form text field for input, the manual entry cannot be mapped from JSM to JPD as that is considered a sub-field. We worked around this either by creating a separate field or creating "Other" as a static option and added in parenthesis to "specify in description".  Not the most elegant solution but it works.