Email Automation Rules

[David Gage]

We receive emails from one of our internal systems to our Service Desk that, by default, come in as the default type (Type: Service Request) and need to be manually moved to a different type (Type: Incident).  Moving the Type from Service Request to Incident is pretty straightforward and simple but we want to automate these types of "tickets".  

I developed the following automation rule to do said task but it fails.

WHEN: Issue Created

IF: Issue Reported: reporter = "do-not-reply@....com"

THEN: Edit Request Type: System Alerts and Errors

            Transition Issue: Investigate

            Edit Assignee: Me

According to the limited error logging available, I found that the "THEN" statements is where the rule fails for the following:

1. Edit request type: System Alerts and Errors
2. Transition issue: Investigate

The 3rd "THEN" statement works, and the 2nd statement fails because it's requiring the 1st to work.  Since the 1st THEN statement is calling the Request Type: System Alerts and Errors, I wonder if it has something to do with that?  

I've called Atlassian support, and after a lot of back and forth, got them on the phone and the only thing they told me was "Yup!  It doesn't work.  Bye."  

This SHOULD work from the built-in Automation rules.

[Olga Videc]

Hello David, 

Okay System Alerts and Errors is a new Request type you created and this issue type is incident, right?

When you created this new Request type (System Alerts and Errors) did you edit this fields?

Because the new Request type should have Summary and Description, Summary is added by default but Description you have to add manually.

[David Gage]

I did create the Request Type from scratch and just looked... I did not add Description to the visible fields.

I just added the field and will wait to see if that helps anything.

[David Gage]

Still not working.  Any other places to check?

[Olga Videc]

Okay, if I got this correctly you would like for your issue to go like this:

• Project - Desktop Support
• Issue Type - Incident
• Status - Investigate (this is only available after the ticket has been moved to Type: Incident).

I'm concerned about this part status to investigate only available after the ticket has been moved to Type: Incident)  how did you active that it has some kind of condition or? 

And how your workflow looks like 

You could try this

Your issue is created goes to 

• Project - Desktop Support
• Issue Type - Service Request
• Status - Waiting for Support

And add automation to do this:

When:

Issue status changed

If: issue matches status Waiting for Support

Than:

Transition issue to Status - Investigate

And (+) adding a second then

Change issue type to System Alerts and Errors

Make sure your workflow suppers the transitions 

Also, you could modify your workflow to go from open to Status - Investigate 

Also like @Jack Brickey said check issue types and request type associated with your workflow, also check our project issue type scheme it should contain all issue types you use.

And I apologize for my grammar and my sentence structure I'm writing on my phone I'll edit it in a hot or two 

[David Gage]

But wouldn't this cause any newly created ticket to have the automation rule applied?

This specific automation rule should only apply to automated emails coming from our anti-malware server.

[Jack Brickey]

A quick thought/question, is it possible that the incoming has a different issuetype with different workflows necessitating a “move”?

[David Gage]

I'm not sure I 100% understand your question but...

When automated system messages come in via email they go to our IT Support address, which creates a ticket and puts it in the following defaults:

• Project - Desktop Support
• Issue Type - Service Request
• Status - Waiting for Support

We're wanting the automated system messages to be moved into:

• Project - Desktop Support
• Issue Type - Incident
• Status - Investigate (this is only available after the ticket has been moved to Type:Incident).

Hope that helps.

[Jack Brickey]

My question is this - are Service Request and Incident associated with the same workflow? If you are not sure please go to project > project settings > workflows and include a screenshot here.

[David Gage]

[Jack Brickey]

Thanks. As I suspected. It seems to me that what is missing here is automation of the move component. So I think the automation needs to look like this...

perform the move in the automation ( when it comes in from email, if whatever conditions, then move to incident and change request type and traction and assign)

in other words in you original post I don’t see the move and I believe that is why 1 is failing. I suspect that the “service alerts and errors” doesn’t exist in the default issuetype.

[David Gage]

I'm sorry.  I don't understand what you mean.  I'm looking in the actions for the THEN statements, but I don't see anything relating to MOVE.

[Jack Brickey]

@David Gage, Here is what I think is happening based upon what you have told me:

• you are trying to change the Request Type to a value (System Alerts and Errors) that does not exist for the current Issuetype (Service Request). That Request Type exists for the Incident Issuetype.
• Before you can change the Request Type you must change the IssueType to Incident

I don't think the OOTB automation will work here but I haven't played with it. You might want to trial Automation for Jira (lite version available for free) which will allow you to edit the issue type.

[David Gage]

Jack,

   I apologize for sounding like a complete muppet, but I'm not understanding how to make that work.  I created the Request Type: System Alerts and Errors (Incident).  And I can't see how to change the IssueType to Incident from the Automation rule set.

Sorry for spamming the images... hoping this will help figure out the problem.  

Thanx,
David Gage

[Jack Brickey]

David,

Are you on Server version of JSD or Cloud? Are the images above associated w/ the native Automation? If so I do not think you can change the issuetype using the native automation. This is why I suggested trying the addon Automation for Jira.

[David Gage]

Server.

[David Gage]

And yes, it's all done from the native automation.  I'm trying to not use or rely on outside Add-Ons.

[Jack Brickey]

As you found you can't Move an issue from one issuetype to another w/ native automation. The Automation for Jira Lite gives you 300 automations/month for free. If that does not work and you simply want/need to go native then....

Is the requirements to switch the issuetype optional? That is what about simply changing the Request Type? If you were to add the "System Alerts and Errors" request type to the Service Request then your current automation should work.

[David Gage]

You would think you could, since what I'm trying to do isn't all that complicated.  I'm not trying to move a ticket between Projects, only re-identify it as a different type.  I'm reluctant to add more Add-Ons, just because it's just more things I'll need to manage.

It's not a requirement to change the Issue Type, but I'm just trying to adhere to ITIL practices and say this type of issue is an incident rather than a (User) Service Request.

I could change the service request type for "System Alerts and Errors" to be Issue Type: Service Request, but I'd still have to manually move the ticket into Incident, wouldn't I?

[David Gage]

Could the problem be with something else in my Project Settings, such as the Incident?  Incident has a different workflow and the initial step that Service Request starts with (Waiting for Support) doesn't exist in the Incident workflow.

Also, I tried looking up three different types of automation Add-Ons and none gave me the ability that I'm looking for - unless I'm not seeing how.

[David Gage]

So, you said previously, that "you can't Move an issue from one issuetype to another w/ native automation".  But why is that?  The native automation ruleset does have a THEN step called "Edit request type".  How is this step to be used?

[Jack Brickey]

I must not be making my point clear. Sorry for that. What I believe  is likely happening is that you are trying to change the request type from one associated with issuetype A to one that is associated with issuetype B.

Here is a test I would request that you try.

1. find an example issue that you would want the automation to succeed  for.
2. go to the detailed issue view and select the requestrian type and see if you can manually change it to the desired issue type

if you can successfully change the requestrian type then you should be able to use the automation you are suggesting. If however, in order to change the requestrian type you have to first change the issuetype then update the request type then this should explain the challenge. Now if this is the case then you can try to first change the issue type in the automation and then the request type.

let me know what you find.

[David Gage]

So I'm looking at the Details: Type: and I'm not able to modify the Type from there similar to how I can with Details: Priority or Details: Labels.  

I can however change it by the MORE: MOVE option.

I guess that's where my confusion for Automation rules comes in.  Shouldn't I be able to create an automation rule if you're able to do it in the GUI?  The only thing I noticed that's different between the two Type: is that the workflow processes have different beginning points.

• Service Request starts with "Waiting for Support"

• Incident starts with "Open"

Thanx...

[Jack Brickey]

@David Gage, to be clear are you trying to change the "issuetype" or the "request type". I'm reading both terms in this thread and as a result I think I have been mixing my answer. :-(

I think you are trying to change the issuetype but for example in your automation screen shot (Tuesday) you are referencing the "request type" which is altogether different. With the native automation, you can change the request type (as you have seen) assuming it exists for the issuetype. However, I cannot find an automation "Then" action for changing the issuetype. There is an Edit Issue but the issuetype isn't in the list of editable fields that I can find.

Now if you were to use an addon app, e.g. Automation for Jira then that capability is present.

[David Gage]

What I want to change is the the Issue Type, but the only way I can see to do it from an automation rule is to change the Request Type (which has a different Issue Type associated with it).  Of course, I'd like the Request Type to change too, but the priority is to have the Issue Type changed.

I noticed this when I was looking through the Automation rules.  I'm guessing this is a telling detail, but I'm not sure how to decipher it and what it means as to why my automation rule doesn't work.

[Jack Brickey]

@David Gage, With the native automation you can only change the Request Type (RT) not the Issue Type (IT). Further, as the error is trying to convey, you can only change the RT if the new RT is associated with the current IT. If you want to change the IT you may want to try Automation for Jira or Automation for Jira Lite (free - 300 automations/mo).

Here is an example that I hope will explain the error message you are seeing.

Let's say you have the following situation:

Issue Type "ABC" with these Request Type: apples, bananas, oranges

Issue Type "DEF" with these Request Type: apples, pears, grapes

So, if an issue is created of Issue Type "DEF" w/ Request Type of grapes and your automation wants to change:

• RT to apples then it will succeed because apples is associated with the current "DEF" issue type. however...
• a change to bananas would fail because that RT is NOT associated w/ the incoming IT 

I hope this makes sense. I believe we have fully dissected this issue at this point.

[David Gage]

Not to continue beating this dead horse, but just wanted to share with you my experience.

Apparently, Automation Lite for Jira cannot do this either.  I although I was able to get the rule to run, there's a bug in the process that removes the ability to update the status. 

The only fix I could find was to move the ticket to another type (eg - Type:Project) and back into Type:Incident.  Which is to say, not what I want and defeating the purpose of "automating" the change.

I'll keep looking for other tools that might do the trick, but until then... I'll uninstall it and do things manually.

I thought the whole point of Jira was the ability to automate routine functions.  That hasn't been my experience so far.

[David Gage]

I removed the second condition for changing the ticket status to Investigate, until I can get the first rule sorted out.

[David Gage]

I forgot to add in my responses THANK YOU!  I haven't had my coffee yet.

Jack Brickey and Red for your assistance and advice.