Should two different organizations using same jira use the same workflow or separate workflows

[Prashanth Batchu]

Say we have two organizations A & B who are working on an integration project. Both produce software and they need to work together to communicate defects etc.

Here are some scenarios

 A creates an application and B finds a bug in it and vice versa

A creates an application and A finds a big and vice versa

In this situation, the signoff entity is going to be different depending upon the origin of the bug and the organization that created the application.

Is it safe to create separate IssueTypes eg: BugA and BugB and have separate workflows for them?

Or should we just have the standard jira Bug issue type and use a single workflow? Some states may be optional depending upon the scenario.

[Jack Brickey]

I don't see anything in your requirements that would drive me to a different workflow. I would definitely not create different issuetypes. The "which product" can be covered either by different projects, which I sounds like you already have (?) or maybe Components w/in a single project or custom field.

[Prashanth Batchu]

Thanks @Jack Brickey .

Follow up questions

1. Say A & B have their own different sign off processes/guidelines
   1. So, shouldn't the workflow steps be different?
2. I had a hunch that creating new issuetypes should be avoided when the same can be achieved through a custom field or even a tag.
   1. But, if we need to subject A's issues to a different sign off process from that of B, wouldn't we require creating a separate issue type?
3. Say we create two different issue types (Ai & Bi) and two different workflows (Aw & Bw). First issue type is mapped to the first workflow Ai -> Aw and Bi -> Bw. This allows us to follow different sign off steps (and different workflow steps) for each issue type.
   1. Is there a way to acheive this without create new issue types and new workflows (i.e with a single workflow)

[Jack Brickey]

When you speak of “sign off process” does that equate to workflow? If your teams need/want different workflows then certainly consider us8ng different issuetypes. It is difficult for me to covey what I might consider to be the best solution without really understanding your process details. I might consider a single project with different issuetypes for the teams or I might have two projects. You could consider a single type and workflow with different paths within the workflow. I would only do this if say there was one or two differences. For example let’s say team A wants a simple To Do, In Progress and Done, but team B wants an extra step, say In Review before Done. You could control the issues that could go to In Review via a Condition in the workflow.