Inheritance of Relation

[B_Sp]

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

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:

@Chr1sG

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!

[Chr1sG]

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.

[Oshyan]

Oo, I like those 4 options, nice flexibility.

[Polina_Zenevich]

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.

[Chr1sG]

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’).

[Dominic]

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.

[B_Sp]

Good to get your vote on this @Dominic !

[Yuri_BC]

@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.

2. 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”.

3. 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.

4. 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.

5. 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.

6. 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.