Creating default values creating new cards by board

[Kyle Phillips]

Discussion has been addressed on this ex. https://community.atlassian.com/t5/Jira-Software-questions/Can-you-set-default-values-for-fields-on-a-Scrum-Board-based-on/qaq-p/780047 and others but teams within a project have their team specific boards and do not operate the same.  Different working agreements/ways of working and so on.  Teams with their own boards should have the ability to default fields based on their type of work within the project.  Also, the ability to stop cards moving from columns if they do not meet sub-tasks signoffs for example.

[Trudy Claspill]

Hello @Kyle Phillips 

Welcome to the community.

I am unclear if you have presented an issue on which you are asking for input, or if you are stating how you think Jira should be designed to work.

Is there a question/issue with which you need help? If so, could you try restating it?

[Kyle Phillips]

little of both.  can we do the mentioned items by board?  if so how is this accomplished and with board ownership.  If not what is the reason and can this be addressed?  Teams clearly do not work the same within a project.   As we are not to compare teams to another they do not operate the same.

[Trudy Claspill]

There are lots of things that can be done to customize how Jira functions, but we need to understand better the problems you are trying to solve.

Boards are just a way to view and manipulate issues. Boards themselves do not impose functionality on the issues. Also, any given issue can be included in multiple boards, since boards show you issues based a filter that specifies which issues to show.

An issue lives in a Project, and the configuration of the Project determines the functionality imposed on the issue. So, you are extremely limited in affecting the functionality of a subset of issues in a single project based on them being present in a specific board.

Let's take the example of workflows (the Statuses to which an issue can be assigned, and the rules for changing an issue from one Status to another).  In the example of workflows specifically, each project is assigned a Workflow Scheme. The Workflow Scheme is comprised of multiple Workflows where each Workflow has been associated to an Issue Type (i.e. Story, Epic, Sub-task). Within a Workflow Scheme an issue type can have only one Workflow applied to it. And a project can have only one Workflow Scheme.

So, if you have teams all working in one project, and all using the Story issue type, they will all have to use the same Workflow for that issue type.

Now, given that, it is possible to add customization that can affect the workflow, and those could potentially be based on the Team (not the board). For instance, if you had a field in the issue that specified the Team that owned the issue, you could potentially customize the workflow to, for instance, not allow the changing of columns for the Story issue type if sub-tasks are not signed off when the Team field is set to "Team1". Some of those more sophisticated customizations may require addition of third party apps to your instance. In the past I did some pretty complex workflow conditions using Adpatavist Scriptrunner on Jira Data Center.

If your teams really do not work the same, you essentially have two choices:

1. Customize your one project to have different issues types per team that will allow you to do the customizations per team that you desire.

2. Have the teams work in different projects so that they can use the same issue types, but customize the functionality that goes with those issue types.