Two diverging workflows - same database same issue type

[Piers Sutton]

Hi! I think the answer to this is no, but still wanted to see if it's possible. Basically we'd like to setup two unique workflows in the same database and associated with the same issue type (bug for example). Is this possible? For example:

Bug created with status of Open
Status changed to either Internal or External each of which would have differing transitions, steps/statuses, but same resolutions.

Thanks.

[Nic Brough -Adaptavist-]

Um, actually, no, it won't work.

The short answer is that there is no way to associate two workflows with one issue type.

What you can do (and I think you already kind of got this), is branch at a workflow level. You have a single workflow that allows two routes, and it never really converges. I.e. an issue is created, the user is offered "internal" and "external" as the only two transitions, and once they select one, the following steps never come back to a step the other branch can get to.

If you're willing to get a bit more clever, you could actually share steps - with a plugin to set a custom field value, you could

• Set up a custom field (select list?) with potential values of internal and external. Don't allow the user to edit it (keep it off create/edit/transition screens)
• Use a plugin post-function to set the value to external when the user selects external transition, and similarly for internal.
• When the workflow converges on a step, and then needs to diverge, add conditions to the transitions out of that step (e.g. if "external" flag is set, don't allow transition "internally closed")

I must say that I like Eddie's point too - I don't think changing an issue type is easy in workflow, but having two issue types (and workflows for them) definitely gives you a lot more flexibility around fields and so on. Plus, two more simple workflows without fuss around post-functions and conditions.

[Piers Sutton]

Thank you both for the insights here. I did think about having two issue types with a unique workflow for each, but unfotunately at the time a ticket is created there is frequently a potential that what sometimes is handled by the internal workflow ends up being assigned out to those responsible for the external workflow. So, if we can't change the issue type after creation, or branch the workflow post creation, we're still stuck I believe.

I like your idea about the custom field, Eddie, and you're right about changing issue type not being easy in workflow. We're going to go over this a bit more and see if there's a solution that works for us that tracks some of these unique but different workflow steps in a custom field.

[EddieW]

Yes, I think the simplest solution would be a common triage pattern.

Tickets with a type of bug, and a status of open has 2 workflow options {"start internal resolution","extenernal"}

then, those new stages { "In Porgress - Internal", "In Progress - External" } in turn have their unique transitions, until at some point they all come back to the default "resolve" transition.

The newer jira have a visual workflow manager that would make that easy to implement.

Another option would be to actually use the "bug" workflow to change the type of the ticket. Then each new type could have their own workflow, both including the standard resolve step.

This is a bit more complicated, and although it would allow more flexibility (different field, notification, visiblity schemes for instance) it might be cloudy to setup and adhere to. (for istance preventing an internal dev from just creating one of the secondary types directly. though you could use transaitions to enforce that beahvior as well)