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

"Request type is one of" Compare Condition Fails Randomly

Erin Blomert

Hello,

The user's problem was solved in this case by Atlassian telling him that next-gen projects handle request types differently, but I am running a company-managed project and their solution does not make sense to me.

I have an automation that creates subtasks for a particular request type when it transitions through a workflow phase.

This condition fails roughly half the time the automation runs, even when the request type is the correct request type. Recently, it worked for one agent and then did not work for another agent on the same day, even though both are in the same groups and have the same roles. The actor is Automation for Jira. I have not been able to make it fail for myself.

Does anyone have any suggestions?

Accepted answers

Jack Brickey

The first thing I would do is prove your theory, if you haven’t done so already, about the request type being “one of”. Add an event log action and record the request tight. Then when you see a failure check that audit log and see what value is recorded. Are use the event log action quite a bit in scenarios where I’m seeing failures and I’m not sure why.

Mark Chaimungkalanont

Can you try adding a "Re-fetch issue" action before the condition? It might be a problem with the timing of when the request type is updated

Erin Blomert

Okay, this is utterly mad, but @Jack Brickey and @Mark Chaimungkalanont were both right.

I am recording this here in case someone else needs to find the solution.

The situation:

1. The automation is triggered by a status change, and the status change is the result of an approval.

2. If the Approver is a agent, the automation can see the request type. If the Approver is not an agent and is only a customer, the automation does NOT read the request type.

This was made evident by the logging Jack suggested.

The fix:

Follow Mark's suggestion and add a "Re-fetch" step immediately after the trigger. For some reason, this allowed the condition to read the request type, regardless of the Approver's identity.

All comments

Jack Brickey

Mark Chaimungkalanont

Can you try adding a "Re-fetch issue" action before the condition? It might be a problem with the timing of when the request type is updated

Erin Blomert

I could try, but the request type is never updated in this workflow. It is created as that request type and is there before the automation is triggered by the workflow transition.

Erin Blomert

That's a good idea Jack, I will try that. I'll update here if I figure it out.

Erin Blomert

@Jack Brickey you were on to something...

I was finally able to make it fail for myself - When the approver is a customer approver, not an agent approver, for some reason it does not pick up the request type field. Ever heard of this elsewhere/any fix ideas? The log action does work in other scenarios...

Jack Brickey

Hi Erin, so are you saying that the customer request type is actually set and you can validate this when you look at the detailed issue view but The automation doesn’t recognize this?

Erin Blomert

Okay, this is utterly mad, but @Jack Brickey and @Mark Chaimungkalanont were both right.

I am recording this here in case someone else needs to find the solution.

The situation:

1. The automation is triggered by a status change, and the status change is the result of an approval.

2. If the Approver is a agent, the automation can see the request type. If the Approver is not an agent and is only a customer, the automation does NOT read the request type.

This was made evident by the logging Jack suggested.

The fix:

Follow Mark's suggestion and add a "Re-fetch" step immediately after the trigger. For some reason, this allowed the condition to read the request type, regardless of the Approver's identity.

Welcome!

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

Quick Links

Find more posts tagged with

cloud

automation

jira-service-management-cloud

jira-service-management