I’m trying to get a view inside of my Sprint entity to contextually display the following levels, but it’s not playing nice with the context filters.
The databases are related like this:
Client (1-m) Programs (1-m) Releases (1-m) Iterations (m-m) Sprints
So I was expecting to see an option like this in the context filter:
“Clients from Programs from Releases from Iterations” but I’m getting nothing really close to that.
Could anyone help tell me where I’ve gone wrong here?
“Looking up” a related entity indirectly through multiple levels of relations must be done explicitly.
Create the following Lookup fields:
You might also want:
I would also just add that the info here may be useful, and in particular, a lot of people are tripped up by this:
I appreciate the help, but that didn’t seem to do the trick, although maybe I didn’t articulate my struggles well enough. 
My issue isn’t about getting the context filter to show the hierarchy I want, but that it’s not handling the filtering of the entities that I am expecting it to have.
When looking at a list view within a Sprint entity, I only want to see Iterations that are linked to the Sprint, but I want those Iterations to be visually nested underneath a Client → Program → Release → Iteration hierarchy.
I’ve been assuming that with the power of Context Views, this would be possible, but no matter how I seem to set things up, all Iterations that are linked to the Release are getting displayed, including ones that are not linked to the Sprint.
I created a completely fresh, test database to help show how things are setup:
I will add that this behavior happens across all levels as well, not just Iterations. If the Client has multiple Programs or a Program has multiple releases linked to it, they all show up too.
The context filter literally says:
On the List you see only [Entities] from [Test Sprint 1]
But I “see” many entities that are not.
Maybe what I ultimately need here is the “Formulas In Filters” feature, which is a wall I’ve been running into almost every single day in Fibery. 
I’m a bit confused here, because based on your initial description of the connections between databases:
I don’t know how you have even reached the option to include the database levels in your relation view (in the Sprint entity view):
If I set up my database as you describe, the only options to choose for a list view are Iterations and Sprints, representing the only viable context paths:
Prior to any playing with lookups etc, what other relationships existed (apart from those you initially mentioned)?
Assuming that you do have the lookups in place (so that a Client has a lookup field that shows all related Sprints) then I think the issue is a misunderstanding of how the context filter works.
When I set up like that, I have the option to create the hierarchy as you showed, and the context filter is as follows:
So what is happening is this:
Imagine that the relationship is that of a tree:
Client = trunk
Program = branch
Release = twig
Iteration = leaf
Sprint = insect visiting multiple leaves (!)
Your context view is limited to only the tree trunk (Client) that the insect (Sprint) is on, and for that trunk, show all its branches, twigs and leaves irrespective of whether the insect has visited them all.
The context filter does not just show the trunk + only its branches with twigs that have leaves the insect has visited + only the twigs that have leaves the insect has visited + only the leaves the insect has visited.
Hey @Chr1sG ,
I already had lookup fields equivalent to what @Matt_Blais had mentioned, so displaying the levels in my screenshot was never the issue. Contextually filtering the entities that are actually displayed in each of those levels is what I’m trying to solve, does that make sense?
The context filter seems to only filter out the top level, when I was expecting it to filter out all levels.
I think any of these 3 things would solve my issue:
1. If the context filter was truly applied to “All Databases” like the UI implies it is.
2. If there were unique context filters available at each level
3. If there was a way to add a formula to a filter so I could add it to each database layer.
i.e.
Client: Sprint = [This Sprint]
Program: Sprint = [This Sprint]
Release: Sprint = [This Sprint]
Iteration: Sprint = [This Sprint]
If there’s any workarounds you can think of to get contextual filtering across each database level in a view, I would be eternally grateful!
Not the answer I was hoping for, but it is what it is. Thanks for explaining it so clearly and definitively!
That said, is there a workaround? 
Or am I doomed to manually change multiple filters each sprint until the end of time?
Appreciate your help as always!
I think you are right to point out that displaying the context filter (which only applies to the root level) when the ‘All databases’ section is highlighted is misleading, however, it does say that it is filtering for ‘Clients via …’ not generically ‘Entities via …’.
You are actually on to something that we have had in our backlog, which is to implement context filters as merely a specific case of ‘dynamic filters’ in the greater context of flexible filters including support for formulas.
Unfortunately, we don’t know when we’ll get to it, and no guarantees that the first version will support multiple layers of querying (which I kinda think your case would need if lookups are to be avoided).
My suggestion would be to approach it from the other direction and add lookups to the Iteration db to show the parent Release, Program and Client, and then use a table view with these columns shown:
It’s not a nice hierarchical view, but if you add sorting by Client, then by Program, then by Release, you will get things in a somewhat logical order.
Yeah, if the context filter was only displayed on the root database and not in the “All Databases” section I wouldn’t have assumed it would be applied globally. When you have a lot of databases and relationships, that filtering dropdown gets absolutely insanely full and is basically unusable (half of the options don’t even fit on the screen) so I kind of gave up trying to understand it.
I don’t love having a lot of lookups that make entities look messy/unpure, but that’s just reality of Fibery without more advanced filtering options. If that’s what the first version of more dynamic filters would require, I’d have no problem doing it! Is there a specific feature request somewhere for this I could put a vote on?
Looking at entities in context with other entities is very important to us and probably the biggest reason I’m trying to migrate away from ClickUp and into Fibery. That said, I feel the table view is the least flexible and contextual way to look at our data, which is why list view is so important.
Once the “grouping by fields” feature is done (sounds like it’s a Q1 2024 thing) it will make all the views (especially table view) infinitely more flexible and mitigate our need to have everything displayed in a hierarchal fashion, so I’m really looking forward to that!
I’ll link this topic to the feature in our internal feedback handling, so that will effectively count as a vote 
@Chr1sG further to what @interr0bangr mentioned:
Has there been any consideration of enabling something similar to the Dynamic Relation Filters to allow lower levels of the hierarchy to access the filter?
This way, the context filtering doesn’t have to traverse up the full tree (and guess which field to filter against), but is available as a value for the creator to strategically apply to particular fields at particular levels just like normal filters.
This is something I’m struggling with and would greatly benefit from as well. It is also something that I don’t think formulas in filters are going to address since they need the view context rather than working on any of the entity data.
That would be a valid solution too! I’m not sure how hard these things are for the Fibery to implement but I can tell you that I just spent almost a full day building a crazy amount of ugly formulas and one-off administrative fields across all my databases to be able to solve this with a single filter on the “All Databases” level. It’s still a manual filter that needs to be changed every sprint until the end of time, but it’s better than nothing.
Formulas in fields would still be my #1 preference as a solution because it would help with way, way more than just filtering and I could see myself using it in many other situations.
I came across this limitation too, and maybe its useful to create a dedicated feature request topic in order to collect user ideas around it.
Its useful to give a more descriptive title to this/that topic, such as “Enhanced Contextual Filtering for Hierarchical Entity Relationships in Views”.
