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; } } }

Automation rule, empty fields and status transition

J B_aty2np

Hello, I've got a problem I do not know how to solve. Our tickets can be escalated via an manually triggered automation rule. If the rule runs, the ticket state is transferred to 'Escaleted'. One condition of transferring to this state, that assignee is set. But it is possible to manually trigger before setting the assignee (actually also from every state, e.g. closed/done, this doesn't make sense). This causes the rule to fail, not transferring to 'Escaleted' (but underwater escalating: creating support tickets, sending emails etc, bit of a mess).

An options is to check in the rule if assignee is set, exit/return if not. But the user cannot see this, just nothing happens. Is it possible to throw an error/warning? "Please set assignee first"? Or some other form of feedback to the user?

Preferred solution would be to disable the whole manual trigger button, so the user must follow the path of assigning first. This also solves the problem of being able to escalate after the ticket is closed. (Our support team is capable enough to not do this, but Murphy's law, right? )

Have a nice day.

Edit:

A further explanation how we use things:

So if we want to escalate we use a manual automation trigger to show a screen. Here the user selects what branch to escalate to and give some some information. This automation then creates a new ticket, e.g. a sales issue, and links it to the original ticket. After this, the status of the original ticket is transferred to 'Escalated' (and if sales closes the new ticket, the status is transferred to de-escalated so the user can further solve the ticket).

When a new ticket comes in, the user should first assign it to somebody, then proceed by escalating. But this does not always happen, sometimes they just start working on it. This is of course a user-error.

The manual trigger is not state/field dependent, so also if the ticket is already solved (eg state Closed), the manual trigger can still be clicked. So best case would be to disable the manual trigger if no assignee is set. Or even better, only possible from certain states on the workflow.

Accepted answers

J B_aty2np

The solution for now is to 'cancel' the automation if the assignee is not set, and made it clear to our team to always set assignee first.

All comments

Ugnius Aušra

Hello @J B

So from what I understand, the issue is that users are triggering the rule manually before setting an assignee, and that causes things to break.

Here are a few ideas that might help:

Best option: See if you can disable or hide that manual trigger button until the assignee field is filled in. That way, users literally can't trigger it too early. I believe you can do this with conditions on the trigger itself—worth checking in the rule settings.

Alternative: Add a condition at the very start of your rule that checks if assignee is empty. If it is, just have the rule stop right there (no actions). It won't fix the user behavior, but at least it prevents the bad outcome.

Hope one of these works for you! Let us know how it goes.

Marc -Devoteam-

Hi @J B

Add a transition to all to the status "escaleted"

On the workflow status in the workflow editor, set the checkbox "Allow issues in any status to move to this one"

And add a screen on this transition, add the Assignee field on this transitions and a condition or validator that the assignee needs to be set

No automation is then required.

J B_aty2np

As far as I could find it is not possible to hide/disable the manual trigger. This indeed would be the best solution.

The problem with stopping/not running the rule is that the user does not see this, and does not know why is doesn't run without feedback.

J B_aty2np

Tried it but the screen does not open if the status transition is triggered via automation. If I change the status to escalated manually, the screen does open.

Also if the assignee is set (correct flow of things), the screen still opens, right?

John Funk

Hi J B - You are correct in that you cannot do an auto transition to a status using an automation rule if the transition has a screen or validation rule attached to it.

But I am confused on your exact use case. Can you list a step-by-step what you want to happen when?

Marc -Devoteam-

Hi @J B

Remove the automation, there is no need for automation if you provide a transition screen on the workflow, that can't be used.

So the escalation action is to be done manually, just as you did on triggering the manual automation rule.

So explain to your users, the automation rule is removed and they have make a status change now.

And yes, the screen always shows, even if the Assignee is already set, it will show the current set assignee.

J B_aty2np

Thanks, but the automation also creates a new (escalated) ticket for several branches, sales, dev for example. The manual trigger displays a screen asking for input, what branch to escalate to, reason for escalation and a couple more.

A status transition with a screen does not accomplish this right? We still need an automation for creating a new ticket?

Also in my opinion, if the assignee of the original ticket is set on the escalation screen for creating a new ticket, is implies it is for the new ticket.

J B_aty2np

The solution for now is to 'cancel' the automation if the assignee is not set, and made it clear to our team to always set assignee first.

J B_aty2np

Thanks, I've updated the original post with more information.

Welcome!

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

Quick Links

Find more posts tagged with

cloud

jira-service-management-cloud

jira-service-management