What's the best way to handle Service Desk requests submitted outside the Customer Portal?

Damon Morda June 22, 2014

We are implementing JIRA Service Desk to replace our current help desk system. However, we've run into a technical issue in the way JIRA Service Desk handles issues submitted outside the Customer Portal.

We want to ensure Help desk tickets can be created in three ways.

  1. Customer Portal – Users can submit tickets through the Service Desk Customer Portal.
  2. Email – Users can submit request through email.
  3. JIRA Create button – IT Help Desk staff can click the “Create issue” button within JIRA to manually create a ticket.

ISSUES

  1. My Requests - Tickets created outside of the Customer Portal will not show up in “My Requests”. For example, if I send an email and a ticket is created for my issue, it will not show up the list of “My Requests”. This is because there is a custom field called "Customer Request Type" that is only populated when requests are submitted through the portal. As a result, users that submit issues through email wiill not be able to use the "My Requests" feature.
  2. Manually creating tickets - IT Help Desk staff may receive a phone call or someone may walk up to the desk to report an issue. Therefore, they need to be able to manually create issues, which would normally be done through the "Create Issue" button in JIRA. However, when done this way it also doesn't show up in the My Requests window.

    One workaround might be to allow IT Help Desk staff to submit issues through the Customer Portal on behalf of another user, but I've not seen an obvious way to make that work.

  3. Changing Customer Request Type - I've attempted to allow the IT Help Desk staff to modify the Customer Request Type field indirectly. I did this by creating a separate field that lists all the different requests types on the portal and then upon save, I tried to map those request types to what the official Customer Request Type field expects (i.e., service_desk_name/slug) and programatically update the field, but that didn't seem to work either.

QUESTIONS

I'd really appreciate if others could share how they've worked around or solved these issues. A few specific questions I had include:

  1. How do you handle requests submitted through email?
  2. Have you found an effective way to handle email submissions so that they can show up in the Customer Portal under "My Requests"?
  3. How do you allow IT Help Desk staff to create issues on behalf of another user so that it still works with the My Requests?
  4. Is there a way to update Customer Request Type programatically.

Thanks in advance.

REFERENCES

9 answers

1 accepted

8 votes
Answer accepted
IT Solutions Team June 24, 2014

Damon-

First off, we're using the downloaded version of JIRA in case that makes a difference. And we're just about to roll out our service desk to employees (I haven't tested with email but I think it should work because the automation event should still fire off).

Solution:

Our workaround has been to use the Automation plugin to set the Customer Request Type after a new ticket is created. I set this up based on two comments on JSD-38 (here and here) but I'll summarize here:

  • Type: Issue Event Trigger
  • JIRA Issue Event: Issue Created
  • JQL Expression: project = "IS Service Desk" and Customer Request Type" is EMPTY
  • Action: Edit Issue
  • Edit fields: customfield_10000=is/get-it-help

I setup another "JQL Filter Trigger" to retro-actively fix existing tickets without the field (same JQL expression).

Thoughts:

This sets the Customer Request Type on all incoming tickets that did not come through the Customer Portal (and hence would not have had the Customer Request Type set), so in my experience they do behave like tickets submitted through the portal.

This is definitely not an ideal solution. The issues I've noticed are as follows:

  • JIRA Activity stream fills up with 4 field changes per ticket that does not come in via the Customer Portal.
  • It maps all issues to a single Customer Request Type, which I think could cause a problem if using multiple issue types with different workflows, negating some of the benefit of status mapping that the Customer Portal provides.
IT Solutions Team June 24, 2014

Reviewing this, I just realized that the problem of everything getting the same ticket type could be addressed by creating automation events for each ticket type and adding the ticket type to the JQL query so that the field is set to the correct value.

Matej K
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
June 25, 2014

I wanted to post the solution using the Automation plugin which we use but you seem to have been faster than me :).

As an alternative, we've created a single automation action based on http://blogs.atlassian.com/2014/02/extending-jira-automation-plugin/to 'guess' the "Customer request type" based on the issue type and project key. Then we hooked this action to Issue Created and Issue Moved event, which still results in a field change in the activity stream, but we do not have to configure one rule/issue type.

We do not change the issue type within one portal, but due to the way JIRA issues are published, if an issue type is changed using "Move" dialog, but the project does not change, only Issue Updated event is published, so you might need to react to that one too (or use the JQL trigger).

If your staff creates an issue 'on behalf' of someone, the Automation plugin will pick it up and it should properly show up for the Reporter in his "My requests".

Hope this helps

daniel matthews October 29, 2016

Guys I really need some help here: I tried this but no luck- I am not sure I am putting in the right value for Edit Fields;

my custom request type is customfield_10023=cs-

my custom field name is cs-customer request type

I dont see my issues created manually from the agent view show up in the My Request view for the customer

daniel matthews October 29, 2016

I got it to work- forget it

2 votes
Damon Morda June 24, 2014

Hi Scott,

Thanks for the detailed response. As it turns out, your recommendation was almost precisely what I ended up doing for now until the functionality exists out of the box.

Using the approach described below one can:

  • Specify the customer request type manually when issues were not submitted through the Customer Portal
  • Accept email-based requests and ensure they show up in My Requests
  • Accept manually created requests and ensure they show up in My Requests

It's not ideal, but it's the most seamless we could come up with at the moment.

Our Apporoach

  1. We installed the Automator plugin to allow us to automatically update the Servicve Desk's "Customer Request Type" field. This field is what makes it show up in "My Requests" for the customer.

  2. We created a custom field and called it "ITHD - Customer Request Type", which is a single choice Select List. This field is something our help desk staff can edit and the options include every Request Type that we created for Service Desk.

  3. We created an Automator JQL Filter Trigger rule for every request type. This is the basic template.

    Type: JQL Filter Trigger

    JQL expression: project = "IT Help Desk" and "ITHD - Customer Request Type" = "<Customer Request Type>" and "Customer Request Type" is EMPTY and (status != Resolved or status != Closed)

    CRON schedule: */5 * * * * ?

    Action: Edit Issue

    Edit fields: customfield_10000=ithd/<slug for that customer request type>

  4. We added the "ITHD - Customer Request Type" field to every screen the help desk staff use, so that field can be edited at any point.

  5. We added the "ITHD - Customer Request Type" field to every Customer Request Type in the Customer Portal and made it a hidden field. When prompted to specify the value of the field when hiding it, we set it to the appropriate value based on the type of request. That way when customers users the portal, it will automatically have the right value for the "ITHD - Customer Request Type" to avoid confusion by help desk staff.

The User Experience

  1. Customer Portal Requests - When a user submits a request through the customer portal, everything works as it should in Service Desk. In addition, the custom "ITHD - Customer Request Type" field gets automatically set based on the request type that was submitted.

  2. Email Requests - When a user submits an email, an issue gets created. Once created, help desk staff triage the issue and select a value from the dropdown field for the "ITHD - Customer Request Type" field. Once they save the issue, the automator plugin will automatically update the "Customer Request Type" field and it will then show up in "My Requests" for the customer.

  3. Manual Requests - If help desk staff take a phone call or somebody walks-in to report a problem, we use the Customer Portal to submit the issue. We then goto the ticket and change the reporter to the person that reported the ticket. This seemed to be better than using the "Create Issue" button because a lot of the automation that occurs on the backend happened automatically because we used the Customer Portal.

Limitations

  • Can't change request type - Once we set a value for our customer "ITHD - Customer Request Type" field, it sets a value for the Service Desk "Customer Request Type" field. We have not yet implemented a way to keep those two in sync. So once that value is set, there's no way to change it.

This was a tricky approach, but it seems to be working so far on our end. Hopefully the Atlassian Team comes up with a better long-term solution for us all.

0 votes
recruhr September 27, 2017

Hello, after few hours of testing all possibilities I have found solution how to automatically update Client Request Type when Issue Type changes.

I am updating Client Request Status with this json:

Edit issue, advanced:

{
    "fields": {
        "customfield_10012":"helpdesk/2a52a027-96e1-492c-bf7f-c6cf826b3350"
    }
}

1. customfield_10012 is name of the field (Client Request Type)

2. helpdesk/2a52a027-96e1-492c-bf7f-c6cf826b3350 is project id / key_id

I have found key_id inspecting console. See response from Server when you try to manually update CLent Request Type

I have fount there this line:

... "portalKey":"helpdesk","portalId":2,"key":"2a52a027-96e1-492c-bf7f-c6cf826b3350" ...

0 votes
M December 7, 2015

I'm in a similar situation and having the same issues as some of the others here. Here is where I am currently:

I have the Automator Rule as project="Helpdesk" and "HD - Customer Request Type" = "Email" and "Customer Request Type" is EMPTY and (status != Resolved or status !=Closed)

I have Custom Fields:

HD - Customer Request Type (13607): Options: Email, IT Help, Move, Phone, Access, Hardware Request, Event

Service Desk Issue Types: Same Options as above

Service Desk Request Name: Telecom Support, Get Help with eMail, Request New Hardware, Get IT Help, Account/Permissions, Move Me, Event Setup.

I can't seem to get the syntax correct for my Automator "edit Fields"

Any Suggestions?

0 votes
Andrej V. September 2, 2015

Hello. The solution with Automation plugin is great.

But I have a question. Can I use some kind a trick that automaticaly add project key for this "Customer Request Type" field according to information in what project Issue was created when editing it? For example like this maybe:

customfield_10000=$project.projectkey/My_Issue_Type

Thanks in advance.

Andrej V. September 2, 2015

Found a solution: customfield_10000=$issue.getProjectObject().getKey().toLowerCase()/My_Issue_Type

0 votes
Matej K
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
October 20, 2014

@IT the format normally is projectKey/request-type, so for example it is jra/new-feature

IT October 21, 2014

The correct "new-feature" value was a trick to find (as it had been renamed) but this worked. Thank you!

Olivier Albertini May 8, 2015

If you rename the request type the value doesn't change .... So you need to remember (in the case where you know) the original value at the creation

0 votes
IT October 20, 2014

I've setup the automation rules (both) listed above, but am unable to modify the value of the Service Desk "Request Type" field!

Everything I try results in an error that states "invalid custom field value". I've tried using the request type id ("customfield_13050=10") and the type name ("customfield_13050=Access").

Is there some special formatting in my value that is needed for this field type? I've gotten it to work for other custom fields.

0 votes
David Wueste October 1, 2014

Using OnDemand - severely limited here!

Need to be able to "change" Service Desk "Request Type" - after initial submittal.

Either that or: read email to: alias and use that to specify which request type:

ie. service@domain.com = Support; info@domain.com = Inquiry

Where Support and Inquiry are two different request types.

service@domain.com and info@domain.com are both part of "service@domain.com" email account, where info@domain.com is an alias.

0 votes
Aaron Shipman June 24, 2014

Thanks for Summerising this.

We also are in exactly your position - Really keen to roll out service desk but cant until the above is solved.

Please add my vote to the above - very keen to see serivce desk become something we can use for our customers

Suggest an answer

Log in or Sign up to answer
TAGS
AUG Leaders

Atlassian Community Events