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 
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. 
It seems like I cannot set the Readwise DB as a source for highlights. Any chance of this changing?
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?
Absolutely. Its ability to return real usable and linked results is pretty astonishing. Favorite implementation of AI yet.
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!
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:
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 
But pricing is always hard. Itās a big challenge to find a price point
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!
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.
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. 
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. 
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.
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.