nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

JIRA Automation rule

Anu Anirudhan

Hi Community,

I need your help with this automation in JIRA service desk.

We like to implement the below rule, finding to hard to action this using automation.

1. If the issue is transitioned from "release" to "deployed " status.

2.Add a comment in the ticket that this is ready to review and test and will be auto-closed within 48hrs if no response is received.

3. Delay for 48hrs

4. Check again if there is a response from the reporter,

5. If yes, retain the status to deployed.

6. If no comments within 48hrs, change the issue status to resolved and add resolution screen-done.

I can get it done till 2nd step to add the comment, after that struggling to add delays and if/then conditions.

Please advise.

Thanks

Anu

Accepted answers

Mark Segall

Hi @Anu Anirudhan - This will need to be chunked into two separate rules. As mentioned, step 2 would end the first rule. Then you'd need a follow up rule:

TRIGGER: Scheduled (Daily)
- status = Deployed and status CHANGED BEFORE startOfDay(-2)

CONDITION: Advanced

{{issue.comment.last.author}}
not equals
{{issue.reporter}}

ACTION: Transition Issue

Trudy P Claspill

Hello @Anu Anirudhan

You can't build a delay into a rule. You will have to create separate rules.

Rule 1 handles steps 1 and 2.

Create a separate rule for the remaining steps.

Caveat: I haven't worked out all the details or tested this.

Set that rule to be triggered on a schedule. The rule will need to discern which issues it needs to review. You will have to come up with a JQL to find that set of issues. There are several different options you might use for that JQL.

One option would be to select issues where the Status was changed to "deployed" in a certain period of time using the CHANGED operator

Jira does not have native JQL functions for looking at when or by whom a comment was added. Do you happen to have Adpatavist Scriptrunner available on your system?

If not then you might need to use separate custom fields and separate rules to keep track of when a comment was last added by the Reporter and when the issue was changed to the "deployed" status.

All comments

Mark Segall

Hi @Anu Anirudhan - This will need to be chunked into two separate rules. As mentioned, step 2 would end the first rule. Then you'd need a follow up rule:

TRIGGER: Scheduled (Daily)
- status = Deployed and status CHANGED BEFORE startOfDay(-2)

CONDITION: Advanced

{{issue.comment.last.author}}
not equals
{{issue.reporter}}

ACTION: Transition Issue

Trudy P Claspill

Hello @Anu Anirudhan

You can't build a delay into a rule. You will have to create separate rules.

Rule 1 handles steps 1 and 2.

Create a separate rule for the remaining steps.

Caveat: I haven't worked out all the details or tested this.

One option would be to select issues where the Status was changed to "deployed" in a certain period of time using the CHANGED operator

Jira does not have native JQL functions for looking at when or by whom a comment was added. Do you happen to have Adpatavist Scriptrunner available on your system?

If not then you might need to use separate custom fields and separate rules to keep track of when a comment was last added by the Reporter and when the issue was changed to the "deployed" status.

Trudy P Claspill

@Mark Segall

I hadn't thought about the Advanced Compare option. Good one!

That assumes that the last comment added would be by the Reporter. Wouldn't that fail if the Reporter entered a comment and then another person entered a comment?

Anu Anirudhan

Thank you Trudy !

Anu Anirudhan

Thank you @Mark Segall

This condition, I am bit confused it it should say " equals" to the reporter. If the comment is added by a reporter of the ticket in the last 48hrs , then to auto close the ticket

{{issue.comment.last.author}}
not equals
{{issue.reporter}}

Mark Segall

Thank you!

Yes - But this was the business logic they're going for. I was going to offer an alternative approach, but time got away from me. I would recommend rethinking the process. This is a common practice that I've seen:

On Deployed, give a customer transition option to accept/reject where...
- accept - transitions to resolved
- reject - kicks it to another status that keeps it open for continued dialog
Set up automation that if it stays in Deployed for longer than 48 hours, it gets closed.

This way you don't have to parse commentary to determine if it's ready to close or not.

Anu Anirudhan

Just checking again;

Could the 2nd rule simply say; (Not sure how to create this rule in terms of JIRA automation)

If the issue status = deployed and if the status has remained in "deployed " for last 2 days , then choose resolution to done and auto close it. This action to be scheduled daily.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-service-management-cloud

jira-service-management