April 6, 2023 / Relation filters, breadcrumbs in search, back-references in Documents

Yes, we will check what is going on here

1 Like

So take your example #4060 feature “Embed Content View into Rich Text” - that has the “F” database Icon

Multiple database names can start with the same letter. Databases within different spaces can have the same name. True, that in case workspace is smaller and there are no overlaps it can be less useful.

I also think this isn’t useful since you can create a view of anything, anywhere

Those views can be named the same way, say, “Budget” and only folder name can immediately help you identify what you are looking at and what should you choose. Say, “Q1 2023”, “Q2 2023”.


BTW, if you try to refresh the browser does it help?

Not working for me either

We confirm the problem looking into it

Agreed. That sounds useful. Also in that linked thread the ability to toggle showing/hiding closed entities (with the ability to set the default to showing/hiding globally as well) in search would be great, too.

1 Like

The main limitation I see with the Relation Filters is the same for all the other Filters - you cannot reference field values.

E.g. in an entity view I cannot filter a Relation field show only entities “related to the same Project as this entity”. I can only filter for A SPECIFIC Project, which is useless.

I know that “Fibery magic™” is supposed to accomplish this kind of thing (by some unknown magical rules :thinking:) but it is difficult to trust – I still would like to be able to create concise filter definitions that reference the values of specific fields.

I will not be at peace until I have Formula-based filters :joy:


I think with the use of colors you can solve this. We have no same-named DB’s with the same color, since we took care to set this up since Fibery provides that excellent functionality. I’d be curious how many users actually have that many DB’s with the same name - we have none and it doesn’t seem logical to me to have that many same-named in an instance as all the suggestions around how many db’s you should have in a Fibery Instance that I’ve read in this community suggest limiting your total number of DB’s if you can.

That’s true with views, but I use search primarily to find entities, most views of relevance to me I have starred on the left nav - although not sure that’s an approach others use.

Bottom line I really miss the fact that the search results used to be nice and compact and now we’ve lost about 1/2 the real estate to the breadcrumbs. Perhaps the breadcrumbs could go on the right side, where there is a lot of free space, to keep the number of results intact as shown below?

Since the search results are (were) identifiable based on the first letter(s) of the db name, it is not unlikely that there are databases that (previously) looked the same in search.

1 Like

Huge agree! I genuinely think Fibery would be a much easier sell for other departments in my company, and for new companies entirely, if you could set strict limits on relation options. Even with this update, the potential for user error is too high, which risks bad data. Constantly filtering through unrelated data is also a point of friction that wears on users.

This update is definitely a step in the right direction, but the real impact would be with formula-based filters and a way to disable the “show other” option.

  • the most common example for me is assignees to project tasks. I should only see people assigned to that project, not everyone in my company

Ok, I mean I have “incidents” which are orange, and “ideas” which are blue. My team associates the color (and you can add an icon like a lightbulb to ideas) and we got used to that very quickly, there is never any doubt what DB we are looking at. Again this is a credit to the basic design of DB’s that Fibery did in the first place with the color coding and ability to add an icon to the db badge.

Either way I continue to yearn for the previous list of search results where you could simple see more results. The breadcrumbs are not useful to my team. And, as I watch the feature requests carefully, I will add that I was surprised by this release as I’d not see it discussed in this community at all as something people were looking for.

Hoping this feedback remains useful…

Breadcrumbs were definitely discussed a few times, I’m very happy to see them. I have many docs that share the same name but at different hierarchies with the new nested docs, and also many tasks with the same name “Plan”, “Publish”, and “Invoice for Q2” that need breadcrumbs to make sense with search


We have many databases with the same name. For example: “Task” database is a part of numerous apps in our Fibery instance, as many apps we create are intended to organize and build a process around specific operations or departments in our business, and having a task database for that specific process is important, whilst still being contained within that app and process.

Creating a task in “Inventory > Task” should not necessarily go under “Team Projects > Task” or “Teammate > Task”, if we are intending to keep certain processes separate and contained. Furthermore, we have many entities that have the same name in different databases across different apps. Knowing where they are is extremely helpful.

There are times where we would accidentally select the wrong entity. Additionally, it gives better context for new users of our Fibery instance, as they may not be familiar with the color coding or badge abbreviations.

Lastly, I know you were an advocate for mobile as well. It seems this would also be the most likely design approach for mobile devices.

Overall, I’m very happy to see breadcrumbs as this was a very annoying thing for us.


@Sarah_Arminta @rawkode

Could you check one more time please? The issue was was resolved so you should see back-references for documents now

1 Like

Yes, it seems to be working for me now!

I appreciate you responding to my question! We too have the exact same situation, many types of tasks, but we have named them as such - there would be in our case an “inventory task” and a “project task” since there were no breadcrumbs up to date so that was a way, aside from the icon and color, to distinguish between them.

And to your point @rawkode here:

I’m aware of several discussions around breadcrumbs, but not that they were needed in the search results. And I can see the greater need for docs and views, which can’t get color-coded the way entities can.

The more I look at this, I think that when I see entities with the breadcrumb below that, that actually includes the entity name, that is the real part of this I have the issue with. I have never seen an implementation of any breadcrumb that includes the item itself in the breadcrumb hierarchy. If this were a tool like Wrike or Asana where your atomic entity was a “task” or something that could live anywhere (which is the case with Docs and Views), then yes 100% you’d need breadcrumbs. But entities by definition can only live in one place in Fibery. So something like leaving entities in the search results as a line item, but adding the context to Views/Docs, would still save a lot of screen real estate. We already have a snippet showing in search results for keywords from rich text boxes when you search for them, but up till now individual entities were shown as line items. Reverting back to that I think would be a great solution, but I guess I’m in the minority, so I’ll have to live with losing screen real estate!

I still think my idea a few posts up to add the breadcrumb on the right to save real estate would be worth exploring. In fact it appears the Fibery team was also thinking about the issue I’m discussing, this is from the public roadmap:

And I will add since there is a comparison to Notion here, the need in Notion is greater since you don’t have the color coding and other benefits of DB’s in Fibery, note in the Notion implementation the actual name of the entity/doc isn’t included in the breadcrumb, which is one of the issues with me with the logic around having a breadcrumb for entities. In fact the way DB’s are set up in Fibery is a big reason I’m here and not in Notion, they are vastly superior!

Not the first time I’ve been disappointed with a screen real estate issue - I still hope someday I’ll get a response to this issue about when I declared losing the ability to expand entities across a big monitor


Sorry one more thing - since the breadcrumbs in search is particularly useful for views and docs, would you guys consider adding the public ID of views to be findable in Search Results? I realize this is technically a feature request, but it’s a small item that has come up a bunch for us, since views have public ID’s, and views (not DB’s) are the one thing in our instance that often have the exact same name. So I have this view for example:


If I type the public ID “39” in the search box, it won’t show up.

Thanks again!

I’m not sure what you’re referring to here. The breadcrumbs do not show the entity name (at least not for me they don’t!)

1 Like

This does (should :crossed_fingers:) work as you describe.
When I type in a number, I get any entities with that number as their public ID returned in the results.

Ok @Chr1sG good catch, yes you are correct, I am mistaken. For the 2 1/2 years I have been using Fibery I have just conditioned myself to know which db’s (I still like the term “type” :grinning:) my entities are in. So when I see the db they are in, it looks redundant to me, since in the case of my Fibery instance there was never any confusion to know which db’s entities were in as I’ve been mentioning…and to your other point, I’ll respond to it directly!