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

[Robert Anthony]

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!