Question about Reclassifying Customer Portal Tickets and Tickets Created from Customer Emails

[John Cherniss]

Hello all - we are currently in the process of migrating to Jira Service Desk from HEAT.  I will be functioning in the role of Jira Service Desk Administrator.

Our Jira Core / Software Administrator (who is handling the details of getting Jira Service Desk up and running) has informed me that for tickets that are generated through the Customer Portal, where the customer has made the incorrect category selection from the portal and they went ahead and created the ticket anyway, that Jira Service Desk "out of the box" does not have a way for the ticket to be correctly re-classified in to it's proper category (have the required fields) by either the customer via the Portal or by one of the Jira Service Desk Agents receiving the ticket in the general queue.

I have been informed that the original ticket would need to be either deleted or closed and a brand new ticket would need to be created by the customer in the Portal with the correct selection made for the Jira Service Desk Agent to get the correct fields for the customer's ticket request, or the Agent may just have to create a new ticket on the customer's behalf. I was told the same situation would apply to a Jira Service Desk Request received via email that is auto-created as a "generic ticket" if we allowed customers to create tickets via email.

I've looked at some add-on apps that might address this shortcoming with Jira Service Desk such as (1) ProForma Forms & Custom Fields for Jira, (2) Extension For Jira, (3) Dynamic Forms, (4) Checklist for Jira and (5) Smart Checklist for Jira and just wondering if any of you also had to deal with this same issue and what add-on app solution you implemented to address this issue, so tickets that are incorrectly classified when submitted in the Customer Portal or generic tickets created in the ticketing system via email submission need to be properly classified by the Agent based on the details contained in the email from the customer.

ProForma looks very good as a possible solution and appears to have the most comprehensive features available - but I'm wondering if there is a different add-on app (or if you are using any of the other apps that are mentioned above) that might cost less than Proforma that would meet accomplish the same goal and meet our requirements, etc. Any comments or feedback would be greatly appreciated. Thanks!

[Simon H · Accepted solution]

Hi John,

You have hit upon one of the limitations of JSD, namely the inability to edit the contents of requests after they are created. I'm the product manager of ProForma, so I thought it might be useful to run you through the sequence of changing a request type in JSD with ProForma. It would be great to hear of any other solutions to this problem, as we see it quite a bit. It's also worth noting that there is ProForma Lite, which has almost the same features as ProForma but is free. 

The process in ProForma would be as follows:

• The request is initially created using the wrong request type and wrong form.
• The agent changes the request type.
• The agent sets the initial form to 'INTERNAL' so that it is no longer visible to the requestor.
• The agent adds the correct form for the new request type and sets it to EXTERNAL, so it is accessible to the requestor.
• The agent leaves a comment, notifying the requestor of need to complete and submit the correct for.

One of the benefits of ProForma is that any of the information stored in Jira fields will be carried over from one form to another, which will likely save the requestor quite some time when resubmitting the form. 

Below is a quick example of changing a request from a New Staff Orientation request to New Hire Onboarding request. This was done in cloud, but the functionality is the same in server/data-center.

Regards,

Simon

[John Cherniss]

Thanks Simon for your detailed answer and for the video demo of the process. Very helpful information.

[John Cherniss]

Hello Simon - I have a few follow-up questions for you. We installed ProForma Lite and I've been testing it out today. I found it overall very intuitive and easy to use.  I created 3 ProForma Forms and associated them with the 3 related requests types in the Customer Portal so the Customer can see and create (or modify) Service Requests by using the ProForma forms for the Service Request. I also was able to do as you demonstrated in the video by pulling up as an Agent an original Service Request created by a Customer and was able to change the request type to the correct (intended) Service Request type, then set the original (incorrect) Proforma form associated with the original request type to "Internal" and then select the correct ProForma form for the modified Service Request type, entered the correct information and then set the form to be be External - and then verified when the customer pulls up the Service Request through the Portal, they see the modified ticket and correct fields and all the updated (correct) ticket information. I also was able to configure the 3 ProForma Forms under "Issue forms" so the Service Desk Agent can very easily create Service Requests directly from any of these 3 Proforma forms I created by selecting them from a list or putting in a search string to pull up the correct ProForma form they are looking for to create the Service Request.

So my first question is this: Assuming we purchased the full version of ProForma,  if we have a Generic "Get IT Help" published in the Customer Portal  and we allow customers to send emails that will automatically create Jira Service Desk Request types, do you recommend that we have a ProForma form created for each conceivable Service Request type we have that are represented by unique fields associated with that particular Service Request that should be used, so no matter what a customer creates under "Get IT Help" or via an auto-generated Service Request created by a customer sending an email, the Agent can either attach the correct Proforma form to the original request so either the customer can add information or correct previous information that was submitted, or an Agent can change the original Service Request type to the correct Service Request selection (if the customer selected the wrong Service Request in the Customer Portal, or they used the Generic "Get IT Help" or they sent an email to create a Generic Service Request ticket) and then attach and make external the correct Proforma Form associated with the corrected Service Request type and then make internal the original Proforma Form they originally used?

My second question is:  Can / should all Service Requests when they are designed in Jira Service Desk just use the Proforma defined form in its place, so that's all the customer will ever see (the Proforma form) and the Agent won't have to attach the Proform form if the customer simply missed some detail when they chose the correct Service Request in the Customer Portal but just overlooked entering some information or typed some information in incorrectly?  In other words, they would be able to correct the form by default since the original form they were filling out in the Service Request was the Proforma form and not a form created via the normal process in Jira Service Desk?

Thanks again,

John Cherniss

[Jack Brickey]

So I’m interested in this thread as I don’t agree that the issue cannot be modified in JSD. Now there are some considerations here.

JSD adds a category to issuetypes (Jira Software/Core Issue attribute) called Request types. Request types are what the customer sees (example - Get IT Help, Printer Issue, Access Request, etc) and each RT is associated to an Issuetype. If the customer opens ticket under one RT and it really belongs under another RT then one of two scenarios applies:

• the correct RT is associated to the same Issuetype - Agent can simply change the RT
• the correct RT is associated with a different Issuetype - Agent uses the Move feature to associate the ticket to the correct Issuetype and RT.

i may be missing the issue here and would like to better understand so I can test/learn.

[JJ]

Let's say that a generic request type has 2 fields and now needs to be reclassified into a new request type that has 5 different fields. So we want the user to fill out those additional 5 fields. It's impossible because tickets cannot be edited after the fact by end users. So that means that the agent would need to fill out the additional fields.

The screen the request type belongs to has 40 fields though. So if the agent clicks 'edit' to fill out the 5 fields, it's impossible to figure out which 5 fields are associated to the request type because even if you click the 'view form request' link, the 5 additional fields do NOT appear.

[Jack Brickey]

I see. Yes that is true. However I would contend that this should be the exception especially if in a well designed portal with clear Request Types. Ultimately the agent needs to engage the request and if the find more info is need they simply Respond to Customer and request this info. They would then need to enter that new info into any fields if desired/necessary.

[JJ]

We want to create tickets through email which means we could have many generic tickets that will need to be reclassified. Figuring out what fields need to be filled out when you have a list of 40 is very difficult in Jira Service Desk. The only way is to create a new ticket so that you can see the fields. This is a serious flaw. I'd like to submit a request to have this fixed. 

[Jack Brickey]

Hi JJ, I suspect there are suggestions in JAC that requests some enhancement to how emails are processed. You might want to look there and possibly vote for them. You might also consider reaching out to Atlassian Support or use the Feedback link. The issue w/ trying to make a solution to handle emails and populate many fields is that the emails would need to be well structured to ensure accuracy. If the emails are machine to machine that is a bit more reliable. But human-machine is problematic. Just my $0.02 worth FWIW.