CHANGELOG: October 1 / Create Documents and Whiteboards inside entities, Automatically link entities based on rules

I would be very interested in seeing a Testing / QA app in Fibery, it’s the biggest hurdle that is preventing us from migrating from Targetprocess.

1 Like

Chris, interesting. A little outside of what I can digest in a quick read…

Curious though, have you figured out the basic functionality of this feature per my question below:

I actually didn’t see any true “inheritance” going on. That is, I thought if I had a field, say a multi-select, in one entity, and I linked it to the multi-select in another, the “linked” entity would pick up that value. That’s not happening for me. Was really hoping to get this working for inheriting relations in particular…

Thanks!

The things you’re describing seem to be achievable using Lookups, unless I’m missing something…either for inheriting field values or relations.
For example, if a Project type has a relation to the Dept type (or a multi-select/single-select field called Dept), and has child Tasks, then the Task children can lookup (= inherit) the Dept choice(s) from the Project, right?

OK thanks. Am I missing something, because when I do this, what I wind up with what appears to be a Lookup. As I mentioned, it’s uneditable, and unusable in boards. So if my intention is to make a relationship, and I then choose this newly-available “Automatically link Relation,” what I wind up with is an actual LookUp field that is, as far as I can tell, another “level” of lookup in that it will find these related Entities that are connected by the same field. There are not in fact related.

So keeping with the example we’re using:

If I have a Project

And I have a Task

I relate them…

And I link their common field “Department” with this feature

I get a “Department” field in my Collections area in my Task Entity, that looks like a LookUp to me. Since both “Project” and “Task” are many-to-one children of “Department,” this Collection will then fill in with whatever department the Project is Linked to. But this is not a relationship between Projects and Tasks, as this feature - judging by the way it is being presented - would suggest. This not “inheritance” by any means as I understand what “inheritance” is supposed to mean. Inheritance as I understand it is you have children that actually pick up the value of a field from the parent. In this feature, all that we are doing is showing the common field between the two related items. There is no actual auto association of fields between relations that you create between the entities in the relations when you create them.

This is all not to say that this isn’t a useful feature, it is! But I think it should be presented as a form of extended Lookup.

Thanks again!

Just so that I understand the example you’re making, Tasks are (many-to-one) children of Projects, right?

If Projects and Tasks are both children of Department, what should the behaviour be if a Project is moved from one Department to another? Should its tasks be automatically related to this new Department?

Anyway, here’s what I think auto-relations are useful for: they allow entities of one type to (automatically) be linked to entities of another type, based on one or more of their fields/links having the same values.

So, in the Test Management app I created, I have the following relations
image
There can be potentially dozens of Steps, but I want each Step Result to only link to the correct Step.

So I can link the Step Results to the correct Steps by using auto-relations where they are linked based on two criteria:

  • the parent Test Case for the Step = the grandparent Test Case for the Step Result (i.e. the parent Test Execution’s parent Test Case)
  • the sequence number of the Step = the sequence number of the Step Result

Now that Step Results are linked to the correct Steps, they can extract useful info from the Steps e.g. via lookups.

I think there are often occasions when it’s useful to create relationships automatically based on certain criteria. But that’s not to say that this mechanism is the right tool for what you would like to achieve :slight_smile:

Chris, thanks. Yes, as you state below:

That is exactly what I’d be expecting. As I understand the concept of “inheritance,” it means that one Entity/Record should keep the linked value with another, including when that value changes.

Other than that I’ll need to analyze your explanation in more depth, but as I was stating earlier, I still don’t see where this is more of a lookup feature than actual relation, because the linked relations do not show up in Boards as Rows/Columns available, which is a key part of Related Types as I’ve understood up till now.

Thanks again for the help!

In that case, I don’t see what the drawback is with the existing Lookups. Projects can be children of Departments, Tasks can be children of Projects, and Tasks can use a lookup to get the Department they are (indirectly) part of…
You can use lookups for rows/columns in board views, just like normal relations, but of course, you can’t move the cards between rows/columns, since the lookup is read-only, but from what you’ve answered above, it is the Project that would be moved from one department to another (and the Tasks would then be automatically moved).

Maybe we’re talking at crossed purposes… :-/

Hey I appreciate the help here.

Let me try this one more time as I feel like this is a very useful feature I just can’t quite figure out.

Here is the app in question:

I decided to use a “client” instead of the “department.”

So what I’d like to do is say I have a Project that I’ve already related to a Client. My Tasks have a relationship with the Client, too.

If I do this when setting up the relation:

This looks like a lookup Field.

How can I add a task to that project so that the new task, which is related to the Type “Client,” also gets the same value as the Project’s Client, which you can see there is already filled in with the “sample entity”

Thanks again for all the help!

I’m not sure why you have created a relationship between Clients and Tasks.
Presumably, a Task can only be a child of a single Project (which is a child of a single Client) and therefore creating a simple lookup (not auto-relationship) for the Task type allows each Task entity to have a ‘pointer’ to its Project’s Client.
You can use that ‘pointer’ in much the same way as a relationship field (filters, sorting, board rows/columns etc.) but it is of course read-only.
Given that I can’t see why you would want to change a Task so it is connected to a different Client than it’s parent Project, so I see no drawbacks.

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 either part of a Project, or are one-off, I can do that. This is where the “inherited” aspect comes in.

Another example would be a Conversation with a Client. This Conversation is a child of the Client because I will have many such Conversations with him/her. During that conversation, several tasks may come up. So those are children to the Conversation. But they are also tasks of that Client. Without inheritance, I am going to have to go back and manually relate those tasks to the Client. Again, I don’t want a lookup here as I want the direct relation.

I will play around with this some more on my own, but what I’m missing right now is a good explanation of how this works. Of the most surprise to me is that when you use this field to create a relation, the resulting relation is read-only, just like what you are saying about Lookups. I don’t expect relations to be read-only.

Thanks again!

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?

So in reality, do you have this going on?

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 :slight_smile:

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…

1 Like

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!

Thanks again

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.

Cheers!

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 :slight_smile:

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.

Cheers!

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.

1 Like

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.

We can still unlink docs and whiteboard if we create a table view. So fix for this would be wonderful so that we don’t loose docs and whiteboards.

1 Like