Chris, if you’re up for it, I am looking at your explanation here and trying to understand as I think you explained this well.
Here is what is missing for me. The way the Fibery “App Map” renders, a Linked Relationship looks just like a “normal” one. However, in a Linked One, you can’t add anything, it’s read only, right?
Where the Step and Step Result are not “related” with the typical Parent/Child that is editable?
And here:
Are you getting that from a LookUp that goes: Step Result → Test Execution → Test Case? So you know the Step Result’s “grandparent” through that lookup, so then you say if the “Step Result” has the same, it links to the “Step”?
If so, that makes more sense now I’m getting close to understanding how this feature works I think!
I see now why your need is not solved by Lookups or Auto-relations.
And yes, your understanding of what I was trying to say in my Test management app is right
So at the moment, auto-relations only allow you to ask Fibery to maintain (read-only) connections that you would otherwise have to do manually, and in the specific case when you alway want to link entities based on some shared characteristic(s).
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…
Great thank you Chris, very helpful! Yes would love that functionality. No tool I’ve seen can even do the Lookups, and now this auto-relations, which I think I will find use of, anyway.
Would love to see the ability to build even more sophisticated relations as you suggest in the pipeline, too! This “inheritance” between related entities is something I have not seen in the market yet in a Work Management tool, and definitely not in Notion!
For what it’s worth, I think Coda is actually very strong on this kind of functionality, so it may be able to implement what you need, but it has weaknesses in other ways which make it weaker than Fibery overall as far as I’m concerned.
Yes, I’m well familiar with Coda as well. I’ve spent a great deal of time in both Notion and Coda, of late finding Notion actually superior as a team work management tool due to Coda’s developer-centric UI - it’s hard to configure it to look much different than a jazzed up Google Sheets to everyday users. Notion and Fibery both shine as tools the “average” user can feel comfortable in right away. As I believe you are also implying, let’s hope that much of the powerful automations, conditional formatting, integrations, and formulas of Coda get into Fibery at some point, but with all the other benefit Fibery has that I question whether Coda will ever implement. I’m talking about friendly UI, great UX for non-developers, easier-to-understand relations, better Details Page configuration, superior views (no swim lanes to speak of in Coda), need to do clunky “cross-doc” to bring in multiple functionality, and so on. My experience in Coda left me thinking the founders want to continue to develop it as “a doc that’s an app,” which means it will serve single-purpose needs. And not serve an entire team holistically, something both Notion and Fibery are suited to do.
Yes, I understand your perspective on the drawbacks of Coda and other tools. I just thought you might not have experimented with all of Coda’s capabilities since you said that the ‘inheritance’ feature was “something I have not seen in the market yet in a Work Management tool”
It’s certainly fair to say that no tool has it all yet
Yes good point, it’s possible the inheritance feature I was looking for was in Coda, but the work in configuring formulas to set it up makes it not really a “feature” I think. What I’d like to see is ideally here in Fibery, as relations continue to expand, the addition of the feature as I described it, it would help me a lot.
So to answer your earlier question in more detail:
I’d like to have this happen, and in fact the child, in this case a “task,” would “follow around” the Project if that relation to the Department is changed. Let’s say mid-project you move the Project to another department. It would be great if my tasks could “move along” as well, without having to go back and manually move them, which is what I need to do now.
I might be able to set up something equivalent in Coda, but certainly without the elegance of the way most everything is set up in Fibery, truly no code! Coda stretches it when calling themselves “nocode,” I think they are “low code” +, as you can’t really set up much that is recognizable to average users without a lot of config and formulas, in my opinion.
I think the key challenge of your problem (as I now understand it) is that tasks can live outside of a project and yet still be associated with a department (or client) but when linked to a project, they need to ‘inherit’ the department associated with the project.
I see no way of doing this without at least some conditional logic, whether that’s a Coda formula or something else. Perhaps someone else has bright ideas.
I typically set up a “Misc” catch-all project when I have setups similar to this. Not perfect, but I’ve found there are some benefits over “free” floating tasks. Then you can just stay in the inheritance game again.
Yes, we can, but at the moment, formulas (and lookups and auto-relations) are ‘read-only’, whereas the bit you quoted was more about a semi-deterministic relationship.
I am optimistic that Fibery will eventually support more complexity in relations, like filtered selection:
or more sophistication in formulas, so that they are not necessarily read-only, which is touched upon here:
