"Request type is one of" Compare Condition Fails Randomly

[Erin Blomert]

Hello,

I have a similar issue to here: https://community.atlassian.com/t5/Jira-questions/Simple-Automation-Rule-Not-Working/qaq-p/1610214

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?

[Erin Blomert · Accepted solution]

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.

[Mark Chaimungkalanont · Accepted solution]

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.

[Jack Brickey · Accepted solution]

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. 

[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]

That is correct, the request type is set already.  A manually triggered automation that logs the request type will also pick it up (notice this is the same issue key)

There is one added complexity - that workflow transition from the first automation is the result of an "approved" decision on the workflow.  If the approver is an agent, the automation registers the request type.  If the approver is a customer, it does not.