Jira Cloud Slack : Remove fields in issue creation screen

[Tony Browne]

I want to know if I can choose which fields show on the "Create Issue from Jira Cloud' form? I've got a LOT of fields here and I'd love to be able to exclude a number of them.

Anyone out there got any ideas where I control this?Thanks!

Tony

[Bob Kleinberg]

When you create an issue from Slack, you can choose which issue type to use - and that controls the fields to display.  It should operate as if you were creating that issue type in Jira Cloud directly.  So... this begs the question: "are there two many fields in your Issue Create screen for the issue type, even when you do it from Jira?".  You could create a distinct "Create" issue screen with few fields for that issue type and associate that with the "Create" action, but use the default for the "edit"/"view" actions.  Then, when you create that issue type in Slack, only the "create" view fields could be used.

Or, you could use a different issue type to begin with which has fewer fields.  I'm not that fond of this solution since, once created, the additional fields won't be there unless you move this issue to a different type.  Now.... you could also do a little finessing behind the scenes - create the issue with the more limited field set issue type and have automation move it to the real type on "Create" action (either Jira automation or modify the "Create" transition of the the workflow to do that if you've created that specific reduced field issue type). but that takes more programming effort.
Those are two approaches that came to mind.
Bob

[paul_price]

I believe the problem is Tony wants the Slack Create issue integration to only show the "Request Form" fields. Right now its showing ALL the "Issue View" fields - many of which may be optional fields for tracking but not a required element for work to start. I have the same issue on an off-boarding project I'm setting up. 

[Tokhirjon Sirojiddinov]

Hi Paul
Have you found the way to over come the issue? I have the same issue :( 

[Bob Kleinberg]

The root of both of your problems comes from the confusion between a JSM Request Type and a Jira Issue Type.  In a JSM project, every Request Type gets mapped to a Jira Issue Type (it's a many Request Types can map to a single Issue Type, but not the other way around).  You can see this mapping when you go into a JSM Service Project as a Jira Admin.   In the two screens below you can see that "Incidents" (managed by the Incident Management workflow) have two Request Types BUT both Request Tpes use the [System] Incident Issue type.

Yet, in the Service requests (which all use the Service Request Fulfillment workflow) use a different common Issue type - namely, the [System] Service Request.

Let's look at a Request type settings, say "Service Requests".  Here is what a customer sees when they use the Service Desk Portal for "Fix an account problem":

From the Settings | Request Type | Service Request administration view the Request Form is configured like this:

From there you see the same three fields.  (Instructions is information you would provide to a customer to help complete the form, not something the customer enters.)  But now, lets look at the Issue view tab:

(There are more fields - as indicated by the presense of the scroll bar - I just didn't want to shrink my browser screen any further).

Point is.... the mapped issue type - "Service Request" can capture a lot more info than just what a customer enters... and this is stuff the Service Manager might fill out as they complete the request.

What do I see when I attempt the same Issue Type in the Slack "Create Jira issue" option in a Slack message?  This is what you see: (I have to insert several pictures to convey what is there, but I just put two):

Once again, the scroll bar indicates there are more fields to show.   Let's compare this to what happens when you click on the blue Create button. 

Sure looks like the same fields as the Portal view...  BUT notice the red arrow points to "Use request type fields" corresponding to the MANDATORY "Request Type" field.  Let's turn that off and see what happens...

Once again scroll bar indicates more fields... in fact, these are the same fields that you saw above in Issue tab view of the Request (It's neet that Atlassian has defaulted to showing the corresponding Request fields - which can be toggled).  However, this is where the Slack problem occurs - Slack is NOT using the Request type to filter the fields.

Okay - problem identified - but how do you fix?  Well, until Slack recognizes the difference between Service projects and regular ones (odds are not good on that), one has to get creative.   If this is that important to you to reduce the number of fields displayed in Slack, you'll need to address reducing the number of fields that are in the actual issue type Create view.  This may be tricky because of the way issue types are mapped to Screen Schemes.  Here is the Screen scheme called "Request Fulfillment Screen Scheme" in which the Issue type Service Request (which is the issue type used by the "Fix an account problem" request uses) is defined:

The answer to what you want to do lies in modifying the "Create issue screen" in the above list.  If you remove all the fields you don't want a user to see when creating the issue in Slack (leaving the Edit/View screens alone), then the Slack user will only see those fields.  HOWEVER, as you can see on the left, this screen scheme affects 4 different issue types, which then can affect multiple Request types.  Your best approach, again, if you really, really want Slack users to see just a subset of fields, is to create an issue type specific to that request (e.g., Onboarding Issue type) containing just the specific fields needed for your onboarding process, then create a specific Screen scheme just for that issue type, as well as mapping an Workflow to that issue type (I've grossly simplified the process).  For the Create Issue screen of that new Screen scheme, tailor down the list of fields that a Slack user needs to provide info for.  You can have more fields than that in the new issue type, just have them available for Edit/View screens so that your Service Manager can update additional information.  Sound complicated - well, unfortnately, it could be.   On maybe you've already tailored down the number of Request types and issue types in your Service project and so you can just operate on the Issue type directly without side effects.  Great. 
I will say that if you are not conversant with managing issue and screen schemes and mappings between the schemes, types and workflows, I'd just tell your customers - "Fill in what you know....  we'll do the rest."

Best I can advise you.

Bob