You can use Lookup field in a Subtask and get project from Story, but only if the Subtask ALWAYS has Story.
If Subtask can live without Story, then lookup will not work. However, we are working on automations and for such scenarios it will be possible to create a rule to set Product automatically for every new Subtask you create.
As a general rule (for me anyway) a relation should exist when it is meaningful for the entities to be directly connected. Lookups are about inheriting or inferring information from an existing relation (and is therefore read-only).
So for a simple example, the classic hierarchy of Product → Epic → Feature requires that Features are related to an Epic, and Epics are related to a Product. There’s no reason why you would create a relationship from Feature to Product, since it can be ‘inherited’ from the Epic.
If you need to have a board where all Features are grouped according to their Product, then a lookup works fine. Although it won’t be possible to drag the Features from Product A to Product B, that’s actually quite logical, since a Feature needs to belong to an Epic - if you drag to Product B, which Epic should it belong to?
That makes sense. So how do I configure a sprint planning board with sprints as columns and projects as rows - that includes userStories grouped on project according to it´s “feautre product lookup”?
It depends on how your types are currently related.
Assuming that you have a hierarchy of Project → Feature → User stories and you also have Sprint → User stories
I have features in a separate app with a relation to userStories. Otherwise I have the same setup.
The issue with this is that userStories that are not assigned to a project (only looked up by it’s parent) are not grouped with the associated project. Hence the need to automatically assign UserStories to the same project as it’s parent on creation. Or is there a way to group rows by lookup reference?
When planing sprint you intuitively what userStoris grouped by its corresponding projekt and doing this manly for every userStroy is time consuming.
One workaround I found its to assign UserStories on a Project list and configure filter to only show that project. Automation for this would be great to have.
That makes sense. So how do I configure a sprint planning board with sprints as columns and projects as rows - that includes userStories grouped on project according to it´s “feautre product lookup”?
My Products have a many:1 relation to a Project (a subset of a Project’s scope).
My Tasks also have a many:1 relation to a Project.
Tasks have a many:many relation to Product (maybe none). If a Task is related to any Product(s), they are all related to the same Project.
When I am editing a Product and I create a new Task there, the Task is related to this Product - great.
But the new Task does not “inherit” the Project relation from the Product, even though they both have a many:1 relation to Project - and in this scenario the Task must relate to the same Project as the Product.
Will Automations be able to help with this – i.e., to allow us to instruct Fibery to make this new Task inherit its Project relation from the Product that “fathered” it?
If not, the only way can I see to automate this relation is a webhook
It looks as though you would be best served by linking projects to products, and products to tasks, and just using a lookup to show the project for a given task and a lookup to show all tasks for a given project.
Can a task be linked to a project without being linked to a product?
I’m a bit confused, since you write
Yes, that’s the problem; my Tasks are fairly generic, and may not be related to any Product (though like Products they are always related to a Project).
So there will be situations where Tasks are created that have no Product relation with which to set their Project relation, but those can be dealt with some other way.
A more general explanation of the problem is that since a Task may be related to any number of Products (including zero), there is no “general” way for Fibery to infer what Project a Task should relate to, from the Products relation.
In theory a Task could be related to multiple Products that belong to different Projects (not that this should happen in practice). So I need something more complex than a simple relationship definition to automatically relate a Task to a particular Project.
I am hoping that Automations will allow me to create a rule like: “when a Task becomes related to a Product, and the Task is not already related to a Project, then inherit the Product’s Project relation.”
Anyway, I think this issue is not easily addressable currently, but I fully expect it to be easy with automations, assuming you can describe the rules to be applied.
For example
…what should happen if the Task is already related to a Project? Should linking to a Product be blocked?
I would hope that relations filters might be able to prevent that from happening.
This particular case is just about saving the user from having to manually relate a newly created Task to a Project, when there is enough info available that this could be automated (i.e. the Task is already related to a Product, so its Project can be inherited/inferred).
If a Task already has a Project, this situation doesn’t apply. I would hope that Automations will be flexible enough to allow the outcome to be tailored to the specifics of each situation – so, I don’t want a “general” answer to your question; I want the flexibility to write an “intelligent” Automation that can determine on a case-by-case basis what is the correct answer.
I’m sure that automations will support what you want to achieve.
In the meantime, I wonder if you would consider an alternative: action buttons
You could have a button in Projects (called ‘Create task’) that spawns a new Task and auto links it to that Project, and a similar button for Products, which links it to the Product and the parent Project.
Good solution, though I am concerned about Action buttons proliferating everywhere, for every special case – visual clutter, and a nightmare to maintain.
Thus I asked earlier for:
A “dropdown” action button to select from various Actions (to reduce UI clutter where many Action buttons are required)
Am I missing something, or is this whole thing not caused due to limitations in the visualization? In other words, what i see here is:
The view can’t do what the user expects it to
Based on the limitations of the view, more relations have to be added to try to get the view to work as expected
Automation of some kind is desired to create these additional relations added only to make the view work
There are a couple considerations about this:
We don’t know at this point for sure that automation will solve this particular problem until we see its own limitations
Adding all these additional relations just to get a view to work correctly, complicates the entity view since fields can’t be hidden yet
Should these additional relations need to exist in the first place for the view?
Personally, I see the root cause of this as being limitations that exist with the smart folders and hierarchical lists. If the user is forced into jumping through hoops with additional relations, automation, etc. something else is wrong.
I have run into this same issue where you end up adding all these lookup relations to try to get these views to work, which really makes a mess of the entity and creates a bunch of confusing relationships on it.
That’s a very fair point. Creating fields solely to enable a specific configuration of a group view (table, list, board etc) will lead to field proliferation which is frustrating and clutters up when not needed.
Having said that, I thought perhaps that Matt’s question related to seeing Project information when viewing a single Task (as opposed to enabling configuration of a group view) and in this case, the visible field is the piece of info you need.
My bad.
This is in progress already, there will be Actions button for every Type and it will be possible to define custom Actions for Types via UI (code will still be available for complex cases).