Workflow & Workflow Schemes

[Jade]

I am creating a company wide workflow 'standard', however, should projects have their own 'workflow schemes'? It looks like when using the defaults, that's what happens but would like advise if it is ok to have multiple projects on the same workflow and scheme? We may tweak and improve processes on individual projects but not the 'standard' workflow.

[Himanshi]

Hello @Jade , 

Welcome to the community!

I see you have some queries on using same workflow and workflow scheme on multiple projects. 

Let's start with a little overview of both workflow and workflow scheme(though I am sure you must be acquainted with these details): 

• WorkFlow: Each Jira workflow is composed of a set of statuses and transitions that your issue moves through during its lifecycle, and typically represents work processes within your organization.  You can read more from :https://support.atlassian.com/jira-service-management-cloud/docs/overview-of-jira-cloud-workflows/
• WorkFlowScheme: A workflow scheme defines a set of associations – or mappings – between a workflow and an issue type. As a Jira administrator, you can associate issue types with different workflows within a workflow schemes and then share this association with multiple projects. More can be known from : https://support.atlassian.com/jira-cloud-administration/docs/configure-workflow-schemes/

I would try to bring up some aspects on the table so that you can decide whether it is preferred or not:

• It is important take this under consideration what type of projects are associating the workflow or workflow scheme with. In the longer run different Type of projects lets say Kanban or Scrum or Work Management Or Service managed project could have different requirements. So making changes on default/standard workflow would reflect on other.
• When it comes to use some feature on transition, be it Validator , condition , properties etc  the changes would not be customise to only one type of project or one but on across the projects. 
• Associate feature like Resolve screen or custom screen related with transition (that may would require for JSW project but in JWM project) would not be scoped within a project/ Project type. 
• If your organisation requirement are static across all the projects and would not require customization based the above listed aspect then you can give a thought to standardization but if suspect that customization or dynamic use case may can come in future then my suggestion would be not opt for this approach. 

I hope I was able to shed some insights on possible pros and cons of this approach. 

Have a great day!