🔥 May 30, 2024 / Fibery 2.0 with Highlights and Fibery AI

So I think what happened is that we released the ability to move fields from the lower to the upper section, but we didn’t have a compact visualisation for all field types, so collections didn’t work.
Then we added the ability to choose how you display fields in different ways.

The combination of these resulted in unlocking what @Marloes described, but we didn’t add much fanfare to that!

Consider it a little Easter egg :wink:


Ahh, ok. So for many-to-many connections they will always be on a single level. I do see now that it works as expected when using a many-to-one entities. Thanks for clarifying and sorry for the false alarm. :slight_smile:

1 Like

It seems like I cannot set the Readwise DB as a source for highlights. Any chance of this changing?

1 Like

Highlights depend on the source db having an editable rich text field, and at the moment, the readwise integration has a read-only field.
I’ll check to see if this can be changed whilst maintaining backwards compatibility.


wow. The AI Assistant is already absolutely amazing.

A quick question:
When grouping by lookups (where relations) would it be possible to hide entities in the looked-up DB that do not contain any of the directly-linked entities?
(i.e. if DB A has a list of linked B’s, and B has a lookup to C, can I show B’s grouped by C without having every possible C on my list?)

Did you try it? :slight_smile:

Absolutely. Its ability to return real usable and linked results is pretty astonishing. Favorite implementation of AI yet.

1 Like

I’m not sure that I understood the case correctly, I would be very appreciated if you provide some screenshots.

But my intuition told me, that “Hide empty groups” flag will help you, you can see it on the Filter popup in the “C” database tab.

This is correct! you’ve understood perfectly, didn’t realize this was there. Thank you!

1 Like

I’m late to feedback/questions here, but first of all congrats, amazing, huge release! At the same time I can’t help wondering if there is an intrinsic, technical reason that the Highlights implementation could not have maintained more of the flexibility of previous functionality (with, yes, lesser utility for more intensive purposes, but that’s why you add rather than replace functionality). Why do we have to switch and lose some current capabilities?

Specifically, can we have:

  • Existing link-to-entity/highlights behavior remains for all databases (flexible, goes in References, but no additional capabilities as in new Highlights feature)
  • New highlights functionality applies when user is highlighting from within any database that has been setup to use it
    • Any set of DBs for which you set up special, new, fancy highlights DB shows you that specific type of highlight (call it “structured highlights” maybe?) only when in those DBs

That would be quite simple and intuitive, IMO. Now I’m guessing there may well be a technical reason this wasn’t done, but if it’s more of a concern around user confusion, UI/UX, etc. I really encourage you to try to ideate some solutions for maintaining both. Your functionality in new Highlights is probably great for the intended use case of product teams dealing with feedback, and I’m excited to potentially use it for some of my own needs as well, but I am really conflicted about migrating permanently to a more powerful yet less flexible approach. There are a zillion other potential use cases for flexible highlights, even within a product team. If both can be maintained that would be amazing.


Thank you for the feedback and the question. Let me explain what happened here,

With the release of Highlights, we wanted to separate two functionalities when connecting to entities.

The first use case is when you would like to refer an entity and have a bidirectional search to find where it comes from. For this functionality, you had two options: mention and Link-to-entity. Both of them do the job. The only difference between the two is that Mention brings the paragraph where it is placed, while link-to-entity allows specifying the referenced text. These two options generated some confusion, and they have been used inconsistently. You can still use mention instead of link-to-entity and have the same functionality.

At the same time, we are missing the opportunity to connect two entities, define the connection with attributes, and flexibly connect the source and target using multi-relation fields. This is why we decided to improve the link-to-entity feature and turn it into a Highlight, which is a more flexible and robust solution to connect entities.

For performance reasons, Highlight functionality has some limitations, like 6 sources and 6 targets, and I understand that does not sound good. However, checking the existing implementation, we found that it covers most use cases.

Long story short, I recommend using Mention where you need the Reference functionality and Highlight only those cases when you need to classify and attribute the connection between two entities. wdyt?

Please let me know if you have further questions on this.


It is really disappointing to see that the standard plan got a limit of just 90 days for entity history. We have been using Fibery faithfully since 2019, so years of history, and we frequently have active stuff that will extend for 1 - 2 yrs (long projects, objectives, company themes, etc.). It was actually a shock for me to click the “clock” just now and see only 90 days. To pay over 2/3 more per user just to get that history back, when many users aren’t concerned with looking at that history, just some key administrators such as myself, is not sensible to my team. We don’t need group permissions because we’ve used a workaround for years since permissions took a long time to come out.

Could you guys reconsider including the unlimited history in the regular standard plan? This seems like a copycat of Notion and Coda’s pricing, sadly since I thought you guys were trying to differentiate yourselves from them, where other productivity tools like Asana, Clickup, etc. don’t even distinguish version history. Heck I have a free Confluence account where I have stuff from pre-Fibery days and there isn’t even a mention of a concept of “version history” in their pricing!

Hope you guys can give this some consideration, thanks!


In fact it was changed long time ago in 2021, but we did not enforce the limits.

Now we do. Unfortunately we will not change that, so if you really need an access to entities history changes for more than 90 days you will have to upgrade to Pro version.

Overall, we try to keep Fibery pricing fair and not hugely differentiate between Standard and Pro in terms of features.

I appreciate you getting back to me but it doesn’t change the fact that I had been using that feature as a key part of my Fibery flow, and to see it gone suddenly is shocking. Would have been the same had you implemented it back when you changed the plan. It was nice to not have to pay $20/user to see far back in our history. This now makes me question the decision of housing so much in Fibery, which up till now was by far the best tool I had ever used for this purpose. My team uses Fibery for a ton of stuff, and most of the users don’t need that history, so if I will now have to pay $20 to add, for example, a remote engineer who works in software development on one of my projects, just so the key admins can trace back in the past how entities were created, linked, commented on, etc. that is really going to give us pause. It’s just too expensive.

I guess I’m in the minority on this because nobody else has commented on this situation, and clearly you guys think it’s justified to charge this, but all the same this is massively disappointing. By far the most you guys have ever disappointed - and it hasn’t been often I’ll give you that!


At first, I also felt disappointment. Not about the 90 days version history, but the fact that you need to pay for AI functionality for every team member. Also for those that will never use the AI functions since their role is too limited for that. I really loved the previous set-up via Open AI credit :sweat_smile:

But pricing is always hard. It’s a big challenge to find a price point

  • that results in enough margins for a healthy business;
  • makes all your customers happy;
  • and fits your competitive position.

When I look at Fibery’s overall vision and how well thought out it is, I think they have thought this through as well.

So instead of looking at what it costs, I’ve started looking at what I gain because of Fibery.

If I didn’t have Fibery, I would have had to purchase 3+ tools that cost me a lot more.

So I’m glad that I can build a whole workspace in Fibery. That saves a shitload of time (and thus money).


Just a friendly reminder that @mdubakov is hosting a webinar today on feature prioritization but he’ll touch upon many of the 2.0 features in his walkthrough. In case you haven’t registered yet, you still have a few hours:

See you soon!

I appreciate the response. AI is a big piece of functionality and I can see why that costs more, it does on just about any other tool I’ve looked at. But being able to see past 90 days history in a feature that is basically what other tools call “activity log” is pretty surprising to me, especially since it was included for so long. I get that the team made a mistake and didn’t enforce this, but if it was such a big deal I feel like they would have noticed 3 years ago and closed the loophole then. I don’t think I’m being presumptuous in saying that it probably wasn’t on the team’s radar very high if they let it go so long, but it’s an absolutely huge deal to me. We use that activity log in a similar way to what you find on the competitors that are more “productivity” tools. So Clickup, Asana, Wrike etc. Notion and Coda charge for seeing back further into history, but they are more considered “no-code / note-taking” so it’s disappointing to me that Fibery is essentially doing a copy cat of the model of those tools, which aren’t as readily used for work management, vs the classic tools to manage work, where the Activity Log is an integral part of tasks/projects, many of which last well past 90 days.

I have now actively started evaluating other solutions for the first time in probably 2 years due to this change. It will cost my team possibly well over $1000 annually to get this functionality back, we can’t afford that when most of our users are not admins, but rather guest-level contractors and other non- contributors - but we don’t have any “guest” type in Fibery that I could use - some tools offer lower tier pricing for those users, or don’t charge for them at all.

Again since nobody else has commented on this I guess I’m an outlier so probably I’m looking like a complainer, but this was just a really big deal and I felt like sharing my experience here since this community is generally great and I’ve been in here for years trying to speak unfiltered, which is something @mdubakov has always encouraged!

1 Like

It wasn’t that the lack of enforcement wasn’t noticed, it was rather that it was decided to spend time delivering other new features rather than using developer time to implement restrictions.
As the focus areas have evolved over time, it’s now reached time to do something that could have been done a while back, but had been deprioritised.

1 Like

Thanks for the clarification! I agree that for many purposes the additional specificity and data of Highlights functionality will be an improvement. And although I’d prefer the greater overall flexibility I suggested (maintain all existing functions, just add new Highlights function that has more capabilities with some scope limits), the approach you took is generally fine.

Thinking about it more I realize that my concern is actually this: I want to convert old Link-to-Entity but not necessarily have to set these up as full Highlights DBs and count against the limits, etc. In other words I created some Link-to-Entity previously with zero knowledge or expectation of this change and the limits that would come with it. I was not keeping in mind number of different databases linked to or anything. So can Link-to-entity instances be converted to References somehow instead? Or somehow listed out for me to manually convert? Or am I missing something in how it already works. :smile:

While I understand you having stuff that takes years to complete… why do you actively need the history of that to reference? Are you perhaps using History as a sort of easy, ad-hoc stand-in for more formal documentation of changes or something? Obviously it’s a feature of some value to some customers since it is now in a higher pricing tier, but I figured it was for compliance or some other enterprise-level features. Just curious why and how you use it, specifically.

I see later in the thread you mention using it like some other tools have a full entity “activity log”, e.g. with ClickUp where that is integrated in with the Comments, etc. (a capability I would now appreciate having in Fibery, as you have previously suggested). But AFAIK, although that has some similarities, it’s actually not the same in that it’s not used for - or I think even capable of - reverting changes. It’s not a powerful form of “Undo”. And I do wonder if having that capability as part of the feature in Fibery makes it “heavier”, more resource-intensive, more challenging to implement and maintain, etc. I could be wrong, but I do wonder… If so maybe a potential solution (which would even be an upsell opportunity for Fibery!) would be allow viewing history beyond 90 days, but only changing/reverting beyond 90 days with a higher subscription tier. :thinking:

I will say that some of the newer Fibery pricing - and the overall industry trend - seems to be partly oriented around simplicity and upselling for the SaaS company and its overall administration, rather than necessarily providing the best mix of options so that every customer can pay for the features they actually need. What I mean by that is e.g. that most providers only allow AI features to be purchased for all users in a workspace (that includes Fibery’s new AI pricing). Same here with the Extended History feature.

On the one hand it’s probably the SaaS company’s perspective that they can get a bit more money from the portion of customers (probably most) who do not need AI for every person but are willing to pay for it for everyone so that the people that need it most can use it. On the other hand there are plenty of (usually smaller?) companies for which this is pretty unreasonable and not worth the cost. The wins may be worth the losses for Fibery and other Saas Proivders though, e.g. a company with 25 people paying for 25 AI subs when only 10 people need it, but also a company with 5 people not paying for AI at all because only 2 need it, vs. the gains they might make if they had more bespoke/per-user pricing, e.g. same 25 person company only paying for 10 AI licenses but 5 person company also paying for 2 licenses because they can now justify it. Hopefully those examples make sense. My point is that Capitalism is crappy. :sweat_smile:

All that said I echo @YvetteLans that Fibery still provides great value vs. most of the competition, even with higher pricing for longer history or add-on AI costs. It’s frustrating, even perhaps feels galling, to have that value proposition change after being a long-time user. But I do think for many new users in a similar position just looking at pricing today as “current pricing” and comparing it to the competition (including the several apps they might be able to replace), they’d probably see it as reasonable.

Maybe pushing for implementation of this is another more likely path to a solution at this point? I’m just hoping that looking at the issue from some different angles might help find a workable intersection point between Fibery’s currently firm position on pricing of this feature as-implemented, and your (and probably some others’) needs as a customer. Can these lemons be turned into lemonade by breaking the feature down a little into components useful for more people at a cheaper price (e.g. just “what happened to this entity”, read-only activity feed) vs. those needed more by bigger enterprises (revert? full audit export?)? Or by adding some other feature to make your actual paid for “full” user numbers more representative of your actual employees? I think guest accounts in particular would be pretty great as a new feature…


Do you mean converting Link-to-Entitys to Mentions?

If you start using Highlights, any existing Link-to-Entities can be left as is, or converted to Highlights if they meet the restrictions of the Highlight settings.
Unconverted Link-to-Entitys will continue to exist.

1 Like