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

When the Documents extension is enabled, and is visible as a column in a table view, it’s possible to link any type of view to the entity (not just documents). The same seems to be true for the Whiteboard extension. Is this intended behaviour?

No, this is definitely not. Hotfix this coming soon :slightly_smiling_face:

Extensions provide a one-to-many relationship between entity and document/whiteboard, which means that a document can only be associated with a single entity. Is this going to remain true, or will it become many-to-many eventually?

Yes, we want to keep one-to-many relationship so that left menu will always be in sync with what you see on entity page

When I associate a document with an entity, the document disappears from the sidebar (I guess to be expected, now that it is ‘owned’ by the entity). However, unlinking the document does not make it re-appear, so it seems to become invisible.

We should not allow to unlink a doc from an entity so far - only to link from another entity. Fix for this is coming :slightly_smiling_face:


Shame, I thought it was nice to be able to link to any view

What’s the thinking behind this? Might it not be possible that a user would decide that a document needs to become ‘shared’ among multiple entities, in which case allowing the document to be moved from being ‘owned’ by a single entity to living at the app level (or allowing many-to-many links) would seem to be useful.


Might it not be possible that a user would decide that a document needs to become ‘shared’ among multiple entities, in which case allowing the document to be moved from being ‘owned’ by a single entity to living at the app level (or allowing many-to-many links) would seem to be useful.

That’s our next step. Yep, you’re right, supposedly that’s the way it will be working: unlinking a document lifts it to the app level :slightly_smiling_face:

1 Like

Agree with this, was also surprised to see Trello, and also Jira - which I think was earlier revealed, because both of what these tools do I would be doing 100% in Fibery.

Other stuff on my list that Fibery/Trello/Jira can’t do:

  • so called “VCS” stuff - Github, etc. That’s obviously a big one, although would like to see at some point Bitbucket as we use that
  • Calendar integrations
  • Email integrations
  • Intercom
  • Figma

The last two were at the top of the integrations list as I understood some time ago, along with Github/Gitlab.


I also have been playing with this and not sure how it works. What I was hoping for was a sort of “inheritance” of a field if related entities both had that field. So I was doing this with a “Project” entity, and a “task” entity. I related the two. Then selected a common field “Department.” What I expected was that this would mean if I created one of those entities within the other, and the one from which I created the other had the common field already filled out, the “created” entity would inherit that field. Does this make sense @Chr1sG?

What seems to happen though is when I do this, I get more of a Lookup-type field that can’t be edited. This doesn’t seem like an actual “relationship” as the update here would indicate, since Lookups aren’t actually relationships as I understand, ie you can’t use them in Boards because they won’t show as relating to the entity where they reside.

Would be grateful for some guidance here as this seems like a cool feature but I really don’t understand exactly what you are creating when you add “Automatically Link…” to a relation.

[EDIT: I have updated the app since this post was written, and it is now over here: Basic Test Management app and sharing seems to work now]

So I managed to make something useful using the automatic relations feature: a rudimentary test management app.
The idea is that a Test Case has several ordered Steps (with Action and Expected Result fields), and is linked to one or more Test Executions.
The Test Execution also links to a set of (ordered) Step Results (which have an Actual Result field, to be filled in by the tester when the test is run).
Then by auto-linking the Step Results to the Steps (based on the test case and order number) it’s easy to have a table view for each execution showing action/expected result/actual result for each step.
I also added a bit of logic so that it’s possible to see which execution is the latest for each test case, plus a summary report of all testing.

I hope people will have a play with it and give feedback.

[edit: I have tried to import the app into another instance of fibery and I get an error message:
so hopefully @mdubakov or the team can figure out what’s going on. I think it may be a bug in sharing apps that contain automatic relations]

For the next iteration, I was thinking of adding an action button for the Test Case (‘Execute Test’) which would automatically create a Test Execution and all the necessary Step Result entities, so that a tester only needs to enter the Actual Result data :slight_smile:

There are still some practical issues to be considered/fixed, such as how to handle changes to the test case after it has been executed, but it seems that versioning might be coming from the fibery team at some point, so I won’t try and tackle it just yet :slight_smile:


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…


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
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…


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.