Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Celebration

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root

Avatar

1 badge earned

Collect

Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!

Challenges
Coins

Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.

Recognition
Ribbon

Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!

Leaderboard

Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,460,668
Community Members
 
Community Events
176
Community Groups

"Threaded" or "Forked" workflow tying multiple processes into one.

Hello all,

 

I've encountered this issue before and have had various degrees of success untangling it or simply going with the flow, but this one seems off.

 

A user received a specific request from a Client (Jira only, not Service Desk, this will most likely be adjusted in the future). Earlier it was a simple request issue that was manually "Moved" into separate issue types/workflows of Epic/Task/Story. This was a manual hassle and not really what Move was designed for, so the business decided (Before I arrived) to develop a workflow that encompasses three different workflows. Based on the issue type value, certain transitions and statuses are blocked to allow the user to transition the ticket through the "True" workflow of the issue type. 

 

On paper, it makes sense, the design however, is messy (lots of statuses) and doesnt seem to be the best way to do things. I think there is a big miss on the Triage (pre ticket logging) portion of the process, where the types could be sussed out before the ticket was actually logged, but im not really sure the best way to communicate this on a pushback, because fundamentally the process works, even if it isn't the best way to implement and is very busy. I feel like I'm missing something here, and as I mentioned before, I've encountered this a few different times. Would love anyone elses feedback on the subject as I'm sure im not the only one who has seen this. What are some solutions, communication tips, maybe I should just roll with it, etc? Any feedback is appreciated, thank you!

0 comments

Comment

Log in or Sign up to comment