Can jira align sync to a team project if the team project uses different workflows for each issue

[Matthew Kistner]

1. In our instance of Jira teams use different workflows for different issues types, i.e. The story workflow is different from the bug workflow, which is also different from the task workflow. In JA is it possible to sink these different workflows? Or does each issue type need to be on the same workflow in order to effectively sync to JA
2. Does a team level project  need to have all issues types on the same workflow to sync to JA?

[Matthew Kistner]

To add some context here, in jira we have art level and team level projects. Most of the teams inside the arts use the same art workflow scheme

But the team schemes look something like this.

Story: Open > in progress > testing > pending fix > RFA > accepted or cancelled

Task: Open > In Progress > Done  or canceled. 

So would there be an issues with story level issue types being on different workflows in the same project or is the rec to keep story level issuetypes all on one standard workflow?

Reasoning being is we don't use Tasks as production issues types so they don't require  a testing process.

[Steve Sauser]

@Matthew Kistner Thank you for the detail, this will be a much cleaner answer now.  

You can totally do what you are showing there, the only thing I would do is change the "Done" to "Accepted" in the task workflow.  

I would not go to the Process Flow steps for this small variance as you can map almost everything you have in the Story workflow to the JA workflow for Stories.

I would probably map like this:

Jira	Jira Align
Open	0 - Pending Approval
In Progress	2 - In Progress
Testing	3 - Dev Complete
Pending Fix	*Don't Map, just leave it alone and JA will reflect 3 - Dev Complete still
Ready for Approval (RFA)	4 - Test Complete
Accepted	5 - Accepted

This would allow you to map the workflow the same each time and JA won't care if you never move to 3 - Dev Complete and 4 - Test Complete for Tasks because it would never see the state coming from Jira.  

If you are doing a Bi-directional sync for Stories you will want/need to educate your teams on the usage of the state in JA since you would be skipping one in Story and multiple in Task.  

If you are using the Jira to JA sync (one direction) then you won't need to do any extra steps.  

[Steve Sauser]

@Matthew Kistner In short, you can...but we would advise against it.   

1. Are you looking for individual states (Jira) to move the state (JA) of the issue and visa versa?  
   1. If this is the case then you will need to leverage process step flows in JA for these issue types, which can ultimately be complex to manage, especially if these workflows are different not only by issue type but by Team or groups of teams. 
2. If you are looking for a more simplistic approach then it would be best to think about having some level of conformity so that you have specific workflow states that map to JA. 
   1. Honestly, it is extremely unusual for someone in JA to need to understand the difference between "Backlog" and "Refined" or "Ready for a Sprint" (just example states); typically in JA leaders want to know:
      1. Is it in the backlog?
      2. Is it currently (actively) being worked (In Progress)?
      3. Is it Done?
   2. By defining some common states that are used in all the issue type workflows (such as "Backlog --> In Progress --> Done" OR "Backlog --> Ready --> In Progress --> In Review --> Done" and simply not mapping the "messy middle" and just allowing those states to live in Jira only the complexity or low level work items can be avoided and the teams can still have some additional states available to them. 
3. Do you really want a separate backlog in JA for Bugs or are they really just a type of Story?
   
   1. While JA does support a separate Bug issue type it places those issues outside the primary backlog of work and they only live in the Bug backlog.  
      1. Many groups don't want these separated as they (rightly so) want to manage the prioritization of work the team is working on in a single backlog.  
   2. Making these a type of Story in JA gives you a consolidated backlog.  What this won't do is as easily support such broad workflow differences for each work item type.  

1. It is not required for all the work items to be on the same workflow, however once again this introduces a lot of complexity to what should be relatively simple.  
   1. You will need to share some level of workflow states at a "Story" (which would include any issue type that is not an Epic (Jira)). 
   2. The only other way to think about this would be to manage each Team Project as a "Team Managed" project (Jira) rather than a "Company Managed" project.  
      1. This then requires the admins to manage each individual project differently and the configuration or integration of those projects into JA unqiue each time and will add a rather large tax on the administration team (JA).  
      2. Keep in mind this is not just a workflow mapping (Team Projects) but a field mapping pattern as well so it is not a few clicks it is a much larger administration effort.  

Long term I would advise you to think about in the patterns of "how should we work" both today and the future.  If every single team is unique with it's Jira pattern it typically represents "local optimization" which significantly reduces the organization's ability to leverage transferable knowledge in the organization.  

If each team is unique in such a way, then if a single individual moves from Team A to Team B, not only is there the cost of onboarding to a new space/technology/work but there is an added onboarding cost of learning how to use the same tools a different way.  

[Shannon Wright]

Within the connector you have different sections to map workflow statuses for feature,  Story,  bug and task.  

You can't change the workflows in Align, but you can map them.