Problem: Entities in work hierarchy are orphaned and belong to different scopes of work

Q: Why is it that when I move an epic into a different project, associated features, user stories, bugs and tasks don't move along with it? Is there a way to do this?

A: Indeed hierarchical links (such as Epic > Feature > User Story > Bug) in Targetprocess do not always limit the assignment of all work items to the same Project / Release etc. The system allows these links and does not consider them as invalid ones.

We plan to make it possible to move a Feature with all its Stories across Projects quickly and easily. This action will be released soon.

For other use cases there we can recommend the following workarounds: filtered views, automatic custom rules, webhooks (deprecated) and Automation Rules.

Filtered views

These views may be created and used by power users to detect orphaned entities and correct broken and missing dependencies manually.

Example of such view: Show Features that are parts of Epics from other Projects.

Cards: Features
Filter: ?Epic is not None and Project.Id != Epic.Project.Id

Custom Rules

Use automatic Custom Rules for the use cases that are supported by existing rules. Activate custom rules that fit your needs to prevent issues in future.

If you would like to activate one of the rules or check the status of your existing rules, you're welcome to do the following. Being an Administrator, find them at Settings -> System Settings -> Custom Rules -> Activate.

Most likely the ones below will be most helpful:

• Assign team of a story to all its tasks and bugs
• Assign team of a feature to all its stories and bugs
• Assign a Project’s Team to a User Story
• Assign a User Story’s Feature to a Bug

More rules are on the way. So far we postponed implementation of other missing rules. However, we continue to gather the use cases on UserVoice.

Use cases

Project of Feature vs Project of its User Stories

Starting from v3.11.3 User stories will now follow their parent Feature.

Previously, if you moved a Feature to another Project, its User Stories did not follow the Feature to the new Project. This was fairly counter-intuitive. Starting with this release, if you move a Feature to a different Project, all of its User Stories will follow (as long as they were originally in the same Project as their parent Feature).

If you move a Feature to a Project with a different process, you will get a warning that this change might cause you to lose some custom fields.

Release of Feature vs Release of its User Stories

Incomplete User Stories inherit Release field from their parent Feature when they are assigned to the same Project.

Create a new user story

Release field of a new user story is set from the Release field of its parent Feature. For this purpose, you should create a new user story in the same project where the Feature is.

Assign user story to feature

Release field of a Feature is inherited by open user stories from the same project that are not assigned to any release yet.

Assign feature to a release

Release field of a Feature is inherited by open user stories from the same project with a similar value set into their Release fields.

Let's consider the data sample. User Story U1 is part of Feature F1. User Story U1 is in the same project where F1 is. User Story U1 is not closed. Here are supported actions:

Team Iteration of User Story vs Team Iteration of its Tasks

Tasks inherit and follow Team Iteration field from their parent User Story when User Story and Task are assigned to the same Team Iteration or when Team Iteration field as blank in both of them. In this case, whenever you assign a User Story to some other Team Iteration, the same assignment is made for Task automatically. However, Tasks can be re-assigned manually to other Team Iteration. Then changes of User Story assignments are no longer reflected in Tasks.