Sub-tasks inheriting Team field (customfield_10001) from parent — blocks regional capacity planning

[ansimoes]

Hi Atlassian Community,

I'm looking for help or confirmation on a limitation we're hitting with the Team field (customfield_10001) on Sub-tasks in Jira Cloud.

The problem:
Sub-tasks always inherit the Team field from their parent issue and cannot be overridden — not via the UI, Jira Automation, or the REST API. The error returned when attempting to set it via automation is:
"Issue is a subtask, and inherits the team assignment from its parent. (customfield_10001)"

Our use case:
We use sub-tasks to represent language-specific deliverables under a parent Story, with each sub-task belonging to a different regional team (AMER, APAC, EMEA). Because of the forced inheritance, Jira Plans groups all sub-tasks under the parent's team — making regional capacity planning and workload tracking completely inaccurate.

Why workarounds don't help:

• Linked Issues don't create a Plans-compatible parent-child hierarchy, so hierarchy and time rollups break

• Creating independent Stories/Tasks with a Parent link doesn't behave the same way in Plans as native sub-tasks

What we're looking for:
The ability to independently set the Team field per sub-task, at least as an opt-in per project or field configuration.

There is an active feature request for this: https://jira.atlassian.com/browse/JRACLOUD-88186. 

Has anyone found a working workaround that maintains Plans-compatible nesting AND allows different Team assignments per child issue? Any input is appreciated. 🙏

[Marc -Devoteam-]

Hi @ansimoes 

Yes sub tasks inherit the Team Field from their parent. this can't be individually set.

Sub-task is not designed to be separate action for another team.

Then you need to use a main level work type and link this to an Epic as a Child, so you need to does this on a higher level.

Using Plans, this indeed will not provide you with an accurate planning parent to child, but you can create a view on work based per team.

Based on you use-case, you might need to revise this. In my opinion the main delivery should be a Story and the Story can have linked Tasks based per region with a issue link that they are blocked by the Story and both have the same Epic as parent.

This should give you a correct view in the planing as issue links will show in colour if the planning is of based on Due date (date field used) of the work items. 

Also the dependency mapping will show this.

[Andrey - Guenov Labs]

Hi ansimoes — Marc is right that the inheritance can't be overridden, and it's worth understanding why, because it rules out a whole category of workaround you might otherwise spend a week on.

The Team field isn't stored on a sub-task at all. It resolves from the parent at read time. That's why the UI, Automation, and the REST API all fail identically with the same message — there's no field to write to, so there's no config, no permission, and no API path that changes it. JRACLOUD-88186 is the only lever on the product side.

The route you haven't tried, and the one that keeps native Plans nesting rather than issue links, is to restructure upward instead of sideways. You're on Enterprise, so you can add a custom hierarchy level above Epic:
https://support.atlassian.com/jira-software-cloud/docs/configure-custom-hierarchy-levels-in-advanced-roadmaps/

That lets you shift everything up one rung. What is a Story today becomes an Epic-level container; each language deliverable becomes a real Story with a native parent pointing at it — not an issue link. Stories carry their own Team field. Plans nests Epic → Story natively, so the hierarchy holds, the rollups work, and capacity groups by the regional team on each child. Your original top level is preserved by the new custom level above.

Two honest caveats, because this is a restructure rather than a workaround:

1. Conversion has a real cost. Sub-task → standard work type goes through Bulk change → Move, and you'll need a follow-up bulk edit or Automation rule to set parent on the converted items. Do it on a copy of one project first; the Move screens for sub-task conversion are fussy about field mappings.
2. Estimates move up with the work. If your estimates currently live on the sub-tasks, they'll now sit at Story level, which is where Plans reads capacity from anyway — so this is usually a fix rather than a problem, but check it against how your teams estimate today.

If the restructure is off the table for now, the cheap interim is a separate single-select "Region" field on the sub-tasks. Be clear-eyed about what that buys you: it makes the regional workload data accurate and queryable in JQL, dashboards, and exports, so you can at least report capacity per region while the feature request is open. It will not feed Plans capacity — Plans reads only the native Team field, and nothing you add will change that. It's a reporting patch, not a planning one.