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

:raised_hand: Relation filters

Instead of sifting through an entire Database when linking one Entity to another, pre-filter the options:

  • exclude done and archived work (ex. don’t suggest long-forgotten Projects for a Task)
  • remove irrelevant stuff (ex. stop suggesting sales reps when assigning people to a Bug)
  • ensure a proper process (ex. make it harder to add Stories to an already full Sprint)

It takes one Fibery guru (yourself!) to configure the relation filters — and everyone benefits from a simpler and faster UI.


Configuring filters in relations is exactly the same as on Views — check out our fresh and detailed user guide for more.

Thanks to everyone who has provided their use cases: it helped a lot to shape this functionality! Now let us know if we’ve actually delivered something useful :sweat_smile:.

:bread: Breadcrumbs in Search

In some cases, the location of an item in search results was unclear, making it difficult to pick the right one. Think of two Views with the same name in different folders.

So we’ve added breadcrumbs to search results to help you find the right thing.

:window: Context Views embedded into rich text


It is now possible to easily insert relevant context Views into documents and rich text Fields, both by finding an existing View or by creating a new one right from text.

When searching for context views to embed, only relevant views will be shown based on the context filter. Here are the rules:

  • In a Document (not linked to an Entity) show context views that have some exact entity in the context filter (and hide DB-level context views)
  • In a Feature (or a document linked to a feature) show context views that have Feature Database or the exact entity of any Database in the context filter

:point_left: Back-references in Documents

Bi-directional links are now truly bi-directional when you mention Documents. The list of all the back-references appears at the bottom of each doc.

Note that it does not work for My Space documents (due to privacy reasons).

:link: Sharing for nested Documents

Now you can share nested documents to public and all nested documents are shared automatically. Note that nested views will not be shared though.

:shrimp: Fixed Bugs

  • Chart title is not replaced by the template title
  • Slack-bot: Entity name is always lowercase if the entity is created via slack
  • Read-only user can configure report in some case
  • Duplicate Report does not clone the Database Filters
  • Inactive User in scheduled integration issue
  • Error while convert and duplicate entities which have entity-level context views
  • It is not clear why sync is blocked if there are several DBs in the integration and for one of them fields count is exceeded
  • Number values with units aren’t parsed correctly in new import
  • Whiteboard and Report views are not found in items list in search
  • Nested views order in copied document differs from views order in original doc
  • Use ‘template’ instead of ‘app_gallery’ in History
  • Nested whiteboards get linked to the root doc instead of nested docs when convert document to an entity
  • Editors are not able to create nested views for space-level docs in the left menu
  • Endless loader in DB selector if try to create entity from the text in full-add form.
  • Links in nested view breadcrumbs isn’t clickable for Editors, Contributors, Viewers
  • Failed to convert document to some DBs without any rich-text field
  • Weird behaviour when db level views for different entities have been added to Favourites
  • All operations are executed on behalf of current user who triggered installation if space was created by AI
  • Context view in Favourites still takes into consideration context even after unlinking doc from entity
  • Nested document view missed in Favourites in case they are context ones
  • Wrong behaviour when doc with nested views has been added to Favourites as basic one and then become context
  • Re-assigning context view to another entity isn’t correctly handled in Favourites
  • Error on try to share workspace template

Love it! Great job, as always!


Hi guys, not sure about this one. On initial read, all this is telling me is the Database/type of the entity, but I already have that info with the Database Icon.

@antoniokov when you say this:

Again I’m not sure how that’s relevant, unless I’m missing something. Databases can only live in one Space. So take your example #4060 feature “Embed Content View into Rich Text” - that has the “F” database Icon, so I already know exactly what kind of Entity it is. I don’t need that extra info.

As regards Views having their location, I also think this isn’t useful since you can create a view of anything, anywhere, (which is a great feature), so I’m never looking at where my view exists.

Finally, a big problem here is with the breadcrumbs I can now see fewer results in search. As it stood, I was happy with fact that each entity was just a line item so you could see a full list, for example when clicking “search” with no parameters so you can see a list of where you most recently visited in Fibery - that’s a great feature. But now that list is going to be cut down by quite a few so we can see the breadcrumbs.

I, and many others here active, would really like to see Seeing “Closed” Entities grayed out in Search Dialog as something of real use soon. I find this one of the few times you guys have actually come out with an enhancement that has made something worse - I’d much rather have the old way search was without the breadcrumbs.

Thanks for listening!

Should I be seeing references on these docs?

1 Like

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!