Service Desk - Moving an Issue based on Keywords

[Jarrod Mochnick]

Hello,

We have two Service Desk projects. Each handle different requests. I was wondering if it was possible (preferably out of the box) to automatically move an Issue that is created based on the Summary line.

For example, lets say we have two SD projects. One called Hardware, the other called Software. If someone emails our email channel with 'Software support' in the subject, the automation detects 'software', and automatically moves it to the Software project. We only have one email address for our end users to reduce confusion on which service desk they need to contact.

[Brant Schroeder]

There is no default automation to move issues between projects.  I would suggest having a single service desk project and moving the issues between queues.  This can easily be automated using the automation rules in the service desk.

[Jarrod Mochnick]

I see what you are saying, but we are already well into production with two separate projects. We have two separate teams entirely with different automation rules, SLAs, and others, hence the need for two projects.

Do you know if it is possible with an add-on?

Thanks!

[Brant Schroeder]

I don't know if there is a add-on that will do this.  We run six teams out of a single service desk and started off with multiple.  They have distinct queues, components, SLAs, and workflows.  We use email aliases to help filter and automate email requests.  We use the portal as our main end point to ensure we get good information from the customer and so they can self service.  Combining was not that hard and just took a little training.  

Depending on your organizations structure that might not be the way to go but to move issues the agents have to be agents in both projects. So really the visibility is the same.

[Samuel Wilkinson]

How did you achieve automation with separate aliases? I am working toward this myself.

[Ert Dredge]

I have this need, too, and created https://jira.atlassian.com/browse/JSDCLOUD-5748 to capture the request.

[Brant Schroeder]

We have multiple aliases pointing to our service desk email address.  When they come in the alias email address is added as a request participant.  I am then able to use automation to look for that user as a request participant.

[Andrew Bilukha]

@Brant Schroeder could you please expand on that a little more?  That seems like a great idea, I am want to make sure I am following what it is you are doing.  Is there perhaps a blog or a page that could be followed in order to set this up?

[Brant Schroeder]

Andrew,

  This is what we did.  We had 5 different emails to consolidate into a new service desk. Each of the five emails is turned into an email alias and now points to our service desk email.  

Example:

• email1@example.com (Alias) -> servicedesk@example.com (Service Desk Email Address)
• email2@example.com (Alias) -> servicedesk@example.com (Service Desk Email Address)
• email3@example.com (Alias) -> servicedesk@example.com (Service Desk Email Address)
• email4@example.com (Alias) -> servicedesk@example.com (Service Desk Email Address)
• email5@example.com (Alias) -> servicedesk@example.com (Service Desk Email Address)

If an email is sent to email4@example.com the alias rule ensures that the message goes to servicedesk@example.com but retains the email4@example.com in the To: of the email. 

When the service desk processes the email it adds the address as a request participant.  We then have an automation rule that runs on issue created.  It looks like this:

Issue Created -> If Issue Matches Request Participant in ("email4@example.com") -> Then Edit Component.  We also use Then Edit Request Type depending on the service desk and how they are adding issues to each queue.  

We then filter on the component or issue type to ensure it is in the proper queue.

Hope this helps.

[Andrew Bilukha]

@Brant Schroeder That is great, Brant.  Thank you for the details, much appreciate it. It will do nicely for us. Kudos for that.

[Bryan Partridge]

Brant, wouldn’t the solution you provided be easily modified to move the ticket into a different project instead?

[Brant Schroeder]

You would have to use something like automation lite to move the issue as the default automations do not provide move capabilities at this time.

[Bryan Partridge]

Thanks for the quick reply Brant.  We are new to JIRA SD and are exploring how to setup our external customers (one project for all or an individual project for each; service desk email - one or many, etc.).  You feedback on this conversation has been helpful.

What do you mean by 'automation lite'?  Is this a plugi-in or some other are within JIRA Core/JIRA SD?

[Brant Schroeder]

Automation lite is a plugin that is free and allows for additional functions.  One thing you should consider if you are getting started is to setup a robust portal.  JIRA service desk really shines when you have a strong portal presence and are receiving requests through it.  Having good forms in your portal will save you and the customer time.  You can also tie the portal to Confluence and create KB articles.  This will save even more time as customers use it for a resource and can answer their own questions through self help.

[Olli Suokas]

Hey @Brant Schroeder, was the alias rule created in MS Exchange or some other mail server environment?

”If an email is sent to email4@example.com the alias rule ensures that the message goes to servicedesk@example.com but retains the email4@example.com in the To: of the email.”

if this was done in Exchange, how was it done? I tried to create such mail rule with the admin GUI with no luck :/

[Brant Schroeder]

Our alias rules are created in exchange.  When they come into the service desk the alias is a cc.  I can work to find out exactly how the alias is constructed.

[Ambientia Licenses]

.

[Brant Schroeder]

Sorry for the delay this is what we are doing:

1. There is a Shared Mailbox (email1@email.com) that is enabled as a service account (i.e. AD user object is not disabled). This is what Jira checks via IMAP.
2. There is a Shared Mailbox (email2@email.com). This account uses an Exchange forward, not an inbox redirect rule, to send mail to email1@email.com.  This is how almost all email is delivered to Jira via the email2@email.com email address.