# Inheritance of Relation **URL:** \ **Category:** Ideas & Features\ **Created:** [November 16, 2020, 5:57am UTC](https://community.fibery.io/t/inheritance-of-relation/1175 "2020-11-16T05:57:21Z")\ **Posts on this page:** 13\ **Page:** 1
**Author:** ![B\_Sp](https://avatars.discourse-cdn.com/v4/letter/b/e8c25b/32.png) [@B\_Sp](https://community.fibery.io/u/B_Sp)\ **Post date:** [November 16, 2020, 5:57am UTC](https://community.fibery.io/t/inheritance-of-relation/1175/1 "2020-11-16T05:57:21Z")
I have some situations where I could use an “inheritance” of a Relation. The way this would work is that a related Entity would “inherit,” or pick up, the value of the parent entity. The example I use is explained here: > [@CHANGELOG: October 1 / Create Documents and Whiteboards inside entities, Automatically link entities based on rules](https://community.fibery.io/t/changelog-october-1-create-documents-and-whiteboards-inside-entities-automatically-link-entities-based-on-rules/1023/20): > > Ok thanks. Yes I understand Lookups and they are useful, but I’m trying to accomplish something else: My Clients have both Projects and Tasks associated, so I need both to relate directly with Clients: Sometimes, we do a quick one-off task for a Client, like “raise an invoice” In other cases, we’ll run a full project, which will have a bunch of tasks. But those Tasks should be related to the Client as well. So if I want to see a report of all my Tasks related to that Client, that are eithe… Later @Chr1sG and I discussed that the way to handle this might be through an “inherited” Relation functionality: > [@CHANGELOG: October 1 / Create Documents and Whiteboards inside entities, Automatically link entities based on rules](https://community.fibery.io/t/changelog-october-1-create-documents-and-whiteboards-inside-entities-automatically-link-entities-based-on-rules/1023/22): > > I imagine that the feature could become more sophisticated, for example employing more complex logic as the criteria for linking, and/or potentially, offering a sort of ‘default link on creation’ option, whereby the links are initially made for you by fibery, but _can_ be manually changed/updated in the future. > > If so, this could eventually be useful for your problem. > So perhaps you would have an auto-link rule that says > “On creating a Task entity: > Link to the parent Project’s Client (if there is one) OR > Link to the parent Conversation’s Client (if there is one)” > > Fingers crossed that this sort of functionality is in the pipeline I’m not sure if this would be best solved with some advanced formulas, or perhaps Formula Filters like exist in Coda, but it would be a very useful feature here in Fibery. Hope that’s clear and happy to explain further if it isn’t! ---
**Author:** ![Chr1sG](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/chr1sg/32/3941_2.png) [@Chr1sG](https://community.fibery.io/u/Chr1sG)\ **Post date:** [November 16, 2020, 10:22am UTC](https://community.fibery.io/t/inheritance-of-relation/1175/2 "2020-11-16T10:22:49Z")
For what it’s worth, the Binders app I have used a fair bit deals with this in the following way: You define a calculation for a field (formula type thing) and you choose one of four behaviours: - Calculated and stored (i.e. default value) - Calculated on demand (you click a button to ‘run’ the calculation - Calculated else entered (as long as the calculation yields a valid result, this overrides any user choice) - Entered else calculated (as long as the user has made a valid choice, this overrides the calculation) These options are all independent of whether a field is read-only or not. And for what it’s worth, the current auto-relations option in fibery seems to be a read-only, calculated field, which is why it can’t provide quite what @B_Sp wants. I guess that he needs either the 3rd or 4th type. ---
**Author:** ![Oshyan](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/oshyan/32/11431_2.png) [@Oshyan](https://community.fibery.io/u/Oshyan)\ **Post date:** [November 16, 2020, 8:50pm UTC](https://community.fibery.io/t/inheritance-of-relation/1175/3 "2020-11-16T20:50:47Z")
Oo, I like those 4 options, nice flexibility. ---
**Author:** ![Polina\_Zenevich](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/polina_zenevich/32/480_2.png) [@Polina\_Zenevich](https://community.fibery.io/u/Polina_Zenevich)\ **Post date:** [November 19, 2020, 2:44pm UTC](https://community.fibery.io/t/inheritance-of-relation/1175/4 "2020-11-19T14:44:55Z")
Hi all! Thanks for the interesting idea (as always)! Do you have any real use cases in mind, that would work for your setup? Any pains it would solve? Thanks in advance. ---
**Author:** ![Chr1sG](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/chr1sg/32/3941_2.png) [@Chr1sG](https://community.fibery.io/u/Chr1sG)\ **Post date:** [November 19, 2020, 5:24pm UTC](https://community.fibery.io/t/inheritance-of-relation/1175/5 "2020-11-19T17:24:47Z")
I think @B_Sp’s need is a nice example: a Task could be a child of a Project, but might also live on its own. It would be nice to have a field (Client) for the Task which automatically links to the Client associated with the Project, if there is one. If the Task is an orphan, the user can choose which Client to be associated with the Task. At the moment, it can only really be solved by having a lookup field (Project’s Client - read-only) + a separate relationship field to Clients (only to be used when the Task is an ‘orphan’). ---
**Author:** ![Dominic](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/dominic/32/5348_2.png) [@Dominic](https://community.fibery.io/u/Dominic)\ **Post date:** [September 6, 2022, 9:42pm UTC](https://community.fibery.io/t/inheritance-of-relation/1175/6 "2022-09-06T21:42:54Z")
Reviving an old thread here hoping for this subject to get a bit more traction. So far we’ve been using a combination of lookups and custom automations with javascript to achieve something similar, and it’s been working ok but we’re starting to run into issues with dropdown filters all across Fibery. Being able to create a hierarchical relation tree while keeping the option to manually change some of these relations would be an awesome native feature for Fibery. ---
**Author:** ![B\_Sp](https://avatars.discourse-cdn.com/v4/letter/b/e8c25b/32.png) [@B\_Sp](https://community.fibery.io/u/B_Sp)\ **Post date:** [October 5, 2022, 3:32am UTC](https://community.fibery.io/t/inheritance-of-relation/1175/7 "2022-10-05T03:32:50Z")
Good to get your vote on this @Dominic ! ---
**Author:** ![Yuri\_BC](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/yuri_bc/32/8803_2.png) [@Yuri\_BC](https://community.fibery.io/u/Yuri_BC)\ **Post date:** [August 19, 2023, 8:39pm UTC](https://community.fibery.io/t/inheritance-of-relation/1175/8 "2023-08-19T20:39:19Z")
> [@Polina\_Zenevich](#): > > Do you have any real use cases in mind, that would work for your setup? Any pains it would solve? > Thanks in advance. Some uses cases: 1. **Feedback Collection for Product Features** : - **Relation Chain** : Community Member → Feedback → Feature Request - **Depth** : 3 levels - **Tension** : As an open-source project lead, I struggle to link feature requests to their original community members. - **Solution** : With relation inheritance, a feature request like “Enhanced Security Layer” automatically shows feedback from “Contributor A”, streamlining acknowledgment. 1. **Insight Reporting for Product Development** : - **Relation Chain** : Developer Group → Member Insight → Product Development → Feature - **Depth** : 4 levels - **Tension** : As a product manager, tracing a feature’s development insight back to its source is challenging. - **Solution** : With relation inheritance, a feature like “Optimized Code Structure” shows it originated from “Developer Group B”. 1. **Organizing User Feedback for Product Refinement** : - **Relation Chain** : User → Feedback → Product Version → Feature - **Depth** : 4 levels - **Tension** : Gathering user feedback becomes scattered when associating with product versions and features. - **Solution** : Feedback on “UI Responsiveness” automatically links to the product version and the feature, ensuring relevance. 1. **Product Insight Consistency for Roadmap Planning** : - **Relation Chain** : Insight Evolution → Current Insight → Roadmap Item → Planned Feature - **Depth** : 4 levels - **Tension** : When product insights evolve, updating associated roadmap items is prone to oversight. - **Solution** : An evolving insight like “Mobile-First to PWA Approach” updates roadmap items like “Mobile UI Overhaul” to reflect the new insight. 1. **Targeted Feedback Collection for Product Features** : - **Relation Chain** : User Persona → User Feedback → Feature Area → Specific Feature - **Depth** : 4 levels - **Tension** : Gathering targeted feedback based on user personas for features is challenging. - **Solution** : Feedback on “Collaborative Editing” inherits user persona details like “Content Creator”, ensuring contextually relevant feedback. 1. **Comprehensive Product Feedback Analysis** : - **Relation Chain** : User Segment → Individual User → Feedback → Feature Area → Sub-Feature - **Depth** : 5 levels - **Tension** : Tracing feedback on sub-features to specific user segments is challenging. - **Solution** : With relation inheritance, feedback on “Drag-and-Drop” in “File Management” automatically links to the “Content Creators” segment, enabling targeted refinements. ---
**Author:** ![tomp](https://avatars.discourse-cdn.com/v4/letter/t/3da27b/32.png) [@tomp](https://community.fibery.io/u/tomp)\ **Post date:** [July 18, 2025, 1:53pm UTC](https://community.fibery.io/t/inheritance-of-relation/1175/9 "2025-07-18T13:53:35Z")
I have a dates database, it tracks key dates from organisations and sites, and has meta data for those dates hence the separate database. This dates database allows me to use the timeline feature showing all dates across all sites and organisations. However the lanes functionality of timeline doesn’t work in my use case as the because I have to select a field from either the organisation database or the site database to define the lanes. Sites are children of organisations, as such I would like to auto inherit the organisation name to the sites. then the timeline will work more effectively. ---
**Author:** ![Chr1sG](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/chr1sg/32/3941_2.png) [@Chr1sG](https://community.fibery.io/u/Chr1sG)\ **Post date:** [July 18, 2025, 5:22pm UTC](https://community.fibery.io/t/inheritance-of-relation/1175/10 "2025-07-18T17:22:17Z")
Could you use Sites as lanes, and then choose the option to group by Organisation? ---
**Author:** ![Chr1sG](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/chr1sg/32/3941_2.png) [@Chr1sG](https://community.fibery.io/u/Chr1sG)\ **Post date:** [July 18, 2025, 5:24pm UTC](https://community.fibery.io/t/inheritance-of-relation/1175/11 "2025-07-18T17:24:03Z")
Otherwise, you can just add a formula/lookup on the Dates database, to get the Organisation(s) from the Site(s) and then use this field for the lanes. ---
**Author:** ![tomp](https://avatars.discourse-cdn.com/v4/letter/t/3da27b/32.png) [@tomp](https://community.fibery.io/u/tomp)\ **Post date:** [July 22, 2025, 11:01am UTC](https://community.fibery.io/t/inheritance-of-relation/1175/12 "2025-07-22T11:01:38Z")
No as there is not always a site, but is always an organisation, but thanks for the suggestion 🙂 ---
**Author:** ![tomp](https://avatars.discourse-cdn.com/v4/letter/t/3da27b/32.png) [@tomp](https://community.fibery.io/u/tomp)\ **Post date:** [July 22, 2025, 11:02am UTC](https://community.fibery.io/t/inheritance-of-relation/1175/13 "2025-07-22T11:02:00Z")
I am in discussion with Polina about a rule to achieve this, thanks