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

**URL:** <https://community.fibery.io/t/may-30-2024-fibery-2-0-with-highlights-and-fibery-ai/6240>\
**Category:** Changelog\
**Created:** [May 30, 2024, 9:16am UTC](https://community.fibery.io/t/may-30-2024-fibery-2-0-with-highlights-and-fibery-ai/6240 "2024-05-30T09:16:05Z")\
**Posts on this page:** 1\
**Showing post:** 60

<div class="post-metadata">

**Author:** ![Oshyan](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/oshyan/32/11431_2.png) [@Oshyan](https://community.fibery.io/u/Oshyan)\
**Post date:** [June 13, 2024, 7:07pm UTC](https://community.fibery.io/t/may-30-2024-fibery-2-0-with-highlights-and-fibery-ai/6240/60 "2024-06-13T19:07:39Z")

</div>

> [@kalman](#):
>
> 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?

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. 😄

> [@B\_Sp](#):
>
> 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.

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](https://community.fibery.io/t/add-comments-inline-to-activity-stream/573)). 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.

> [@B\_Sp](#):
>
> 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.

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…

---

_[View the full topic](https://community.fibery.io/t/may-30-2024-fibery-2-0-with-highlights-and-fibery-ai/6240)._
