Help for workflow with approval and automation

[Alixanne FERAUD]

Hi Team,

I am designing a Jira Service Management (JSM) workflow and I need guidance on the most efficient way to implement a conditional branch.

Current Workflow Logic:

1. Trigger: Ticket is created.

2. Initial Status: Pending Approval.

3. Condition: Once the approval is granted, I need the workflow to branch:

   • IF AD attribute (custom field) is EMPTY: Transition to "Open".

   • IF AD attribute (custom field) is POPULATED: Transition to "Pending Information".

Technical Challenges & Questions:

1. Workflow vs. Automation: I understand that standard workflow transitions cannot natively "calculate" this branch during the approval step itself. Is it correct that I must use an automation rule triggered by "Approval Completed" to handle this logic?

2. Logic Execution: What is the best practice to ensure the ticket moves to the correct status immediately after approval without manual intervention? depending on AD filed value.

3. Attribute Fetching: How do you recommend checking if the AD field is empty/full within the Automation engine and/or with conditions in the workflow for the most reliable result?

I want to ensure the workflow is "clean" and doesn't get stuck in a loop. Any advice on the configuration of the transition or the automation rule would be greatly appreciated.

Best regards,

[Chris Hampshire · Accepted solution]

Hi @Alixanne FERAUD 

I understand that you wish to build an automation that will allow the item to transition to one of two statuses depending on the values within the AD Attribute custom field

My answer below assumes that there are no workflow transition rules that would prevent the ticket moving from Pending Approval to either of the two statuses

Your automation would need to look like this. (Note that your automation will need to use branching)

1. Trigger: Work item is created

   1. Branch CURRENT WORK ITEM

   2. IF: Field Add Attribute, Condition: is empty

2. 1. THEN: Transition to Open  

1. Branch CURRENT WORK ITEM
2. IF: Field Add Attribute, Condition: is not empty
3. THEN: Transition to Pending

Apologies the format of above doesnt look great. I have included a screenshot to assist

Note I have used the field stakeholder for reference only. Please use the AD Attribute field you reference here

[Alixanne FERAUD]

Hello, thank you!
I realize you might need some additional information, or that I wasn't clear enough.
This is a ticket for creating an application account.
Step 1 is pending approval.
Once validated, the branch should only be implemented after the ticket has been validated, and so that it arrives in the correct state depending on whether the ad is empty (open) or full (pending information).
(By default, if the ticket is rejected, it goes to closed - but this is perfectly handled in WKFL.)
Can I use your suggestion, taking these elements into account?
Thanks again.

[Chris Hampshire]

Hi @Alixanne FERAUD 

The automation rule I suggested assumed 3 things

• When a user is creating the ticket, they will enter a value for AD Attribute, or they will not
• When the issue is created, the status the ticket initially enters is "Pending Approval"
• Pending Approval and Pending Information are two different workflow states

The automation will run when that ticket is created and will always end up in one of two states either

• Open (if AD Attribute is EMPTY)
• Pending Information (If AD Attribute has a value in it)

So yes, you should see this working when you build the automation

[Bill Sheboy]

Hi @Alixanne FERAUD 

For the scenario you describe, please try the If / Else Condition block:

https://support.atlassian.com/cloud-automation/docs/jira-automation-conditions/#If-else-block

Additionally, as your rule uses a Work Item Created trigger...

That trigger has known racetrack timing defects, so the rule can start running before all of the data is available / stable.  When this happens, the symptoms will be unusual rule errors, missing field data, unpredictable conditions, etc.  Atlassian knows about this defect, and has provided no timeline for when it will be fixed.

To mitigate the problem:

• Always add a Re-fetch Work Item Data action immediately after the Work Item Created trigger.  This will slow the rule slightly, reloading the data before the steps proceed.
• Although you do not use them in your described rule, never use the new feature to add conditions directly in triggers.  As noted above, missing data could make the results unpredictable.  Instead, add separate conditions after the re-fetch action.

Kind regards,
Bill

[Stephen_Lugton]

Hi @Alixanne FERAUD 

I'm reading your request a bit differently from the others, I see it as

Trigger: Work Item approved

Action: 

If AD attribute IS EMPTY then transition to "OPEN"

Else Transition to "Pending Information"

For this explanation I've used status names that exist in my instance.

From your description, I'd suggest adding an additional transitionary status 'Approved':

This is so the following trigger can be used:

Make sure to use this restrict transition rule on the Closed and Approved transitions:

Doing this allows the following short automation to be used:

Note that after Approving the work item, the status of the work item will first change to 'Approved' before the automation kicks in and moves it to Open or Pending Information