-
Suggestion
-
Resolution: Low Engagement
-
None
-
None
-
None
-
1
-
NOTE: This suggestion is for JIRA Service Desk Server. Using JIRA Service Desk Cloud? See the corresponding suggestion.
Problem Definition
Ability to create multiple unique forms under an individual issue/request type
Suggested Solution
Customer can continue to create individual request types, but if they have a requirement to have 20-30 unique forms then customer is going to have 20-30 unique issue/request types which of course would become unmanageable over time.
Why this is important
It would be incredibly useful to have the ability to create multiple unique forms under an individual issue/request type so that you can capture the right information at the first point of contact from the customer. The best example for this would be Service Requests as they can come in all different flavors.
Possible Service Requests that would need a unique form are as follows:
- New employee request form
- Employee leaving form
- Database access request form
- Hardware ordering form
- Software ordering form
- Basically anything that either needs to be approved or tracked.
Workaround
No
- relates to
-
- Gathering Interest
| Form Name | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
[JSDSERVER-4643] Ability to create multiple unique forms under an individual issue/request type
| Resolution | Original: Won't Do [ 10000 ] | New: Low Engagement [ 10300 ] |
| Status | Original: Closed [ 6 ] | New: Closed [ 6 ] |
| Resolution | New: Won't Do [ 10000 ] | |
| Status | Original: Gathering Interest [ 11772 ] | New: Closed [ 6 ] |
Hi,
Thank you for raising and watching this suggestion. We regret to inform you that due to limited demand, we have no plans to implement it in the foreseeable future. In order to set expectations, we're closing this request.
This is an automated update triggered by low engagement with this suggestion (number of votes, number of watchers).
We hope you will appreciate our candid communication and our attempts to become more transparent about our priorities. You can read more about our approach to highly voted suggestions here, and how we prioritise what to implement here.
To learn more about our recent investments in Jira Service Management and Data Center, please check our public roadmap and our two dashboards containing recently resolved issues, and current work and future plans.
Regards,
Charlie
Jira Service Management, Server & Data Center
| Workflow | Original: JAC Suggestion Workflow [ 3012557 ] | New: JAC Suggestion Workflow 3 [ 3647455 ] |
| Workflow | Original: Confluence Workflow - Public Facing v4 [ 2663880 ] | New: JAC Suggestion Workflow [ 3012557 ] |
Jason Hughes
added a comment - Reiss is absolutely correct! We are running into the same problem. It's nice that the Request Types on the portal can be customized...but the fields have to be mapped somewhere. That somewhere is the create screen of the related issuetype in JIRA. The only workaround we have been able to come up with so far is to force an agent to create requests directly in the portal. That way they don't need to be overwhelmed by all the fields we have to add to the create screen in Jira to accommodate all the custom fields we had to add the the create screen of the issue type. We also made sure those custom fields were not part of the edit screen so that the agent again was not bombarded with all of those fields if they go to edit the issue in service desk. The downside to that is that they are not able to change the custom fields. they would only be able to change the other fields. (not very ideal). We made sure the custom fields are on the view screen since Jira will actually only display them for viewing if the field(s) are populated. This is definitely a workaround and is not a good one for sure. It should be easier than this.
The second idea we had was to just have a generic Incident and Suggestion issue type for a Service Desk and they would have to be standardized. No custom versions would be allowed. Then we would create a custom version of issue types Service Request and Service Request w/approvals for each Request Type. That way the portal form could be customized for each one and it would map to it's own custom Issue Type. Again, this would be a nightmare to manage and not idea.
The bottom line is that Atlassian has made the portal very customizable from a Request Type perspective. However, since that information has to map to an issue type in JIRA, the flexibility ends there because as you said in a previous comment, the portal form fields are a sub-set of all the fields available on a specific issue type. From an agent's perspective, you basically have multiple forms from the portal that map to one single large form on the back-end...an Agent's nightmare.
Jason Hughes
added a comment - Reiss is absolutely correct! We are running into the same problem. It's nice that the Request Types on the portal can be customized...but the fields have to be mapped somewhere. That somewhere is the create screen of the related issuetype in JIRA. The only workaround we have been able to come up with so far is to force an agent to create requests directly in the portal. That way they don't need to be overwhelmed by all the fields we have to add to the create screen in Jira to accommodate all the custom fields we had to add the the create screen of the issue type. We also made sure those custom fields were not part of the edit screen so that the agent again was not bombarded with all of those fields if they go to edit the issue in service desk. The downside to that is that they are not able to change the custom fields. they would only be able to change the other fields. (not very ideal). We made sure the custom fields are on the view screen since Jira will actually only display them for viewing if the field(s) are populated. This is definitely a workaround and is not a good one for sure. It should be easier than this.
The second idea we had was to just have a generic Incident and Suggestion issue type for a Service Desk and they would have to be standardized. No custom versions would be allowed. Then we would create a custom version of issue types Service Request and Service Request w/approvals for each Request Type. That way the portal form could be customized for each one and it would map to it's own custom Issue Type. Again, this would be a nightmare to manage and not idea.
The bottom line is that Atlassian has made the portal very customizable from a Request Type perspective. However, since that information has to map to an issue type in JIRA, the flexibility ends there because as you said in a previous comment, the portal form fields are a sub-set of all the fields available on a specific issue type. From an agent's perspective, you basically have multiple forms from the portal that map to one single large form on the back-end...an Agent's nightmare. | Support reference count | New: 1 |
| Workflow | Original: JSD Suggestion Workflow - TEMP [ 2322503 ] | New: Confluence Workflow - Public Facing v4 [ 2663880 ] |
| Status | Original: Open [ 1 ] | New: Gathering Interest [ 11772 ] |
| Workflow | Original: JSD Suggestion Workflow [ 2053999 ] | New: JSD Suggestion Workflow - TEMP [ 2322503 ] |
Would have liked to add more than one form to a request. For example, a terms and conditions that could be applied in multiple places... but if there is only one form per request and we are already using forms there... no way to add it in. We need to customize a lot more in this case where multiple forms would have made it easier.