Hey, @antoniokov just wanted to add as I was thinking about this later today, I think this is the absolute key point in your essay:
You are hitting on here something very fundamental that I think all the apps you talked about have missed out on, and I would love you guys to pursue: I think the tool can actually have just one “Entity” type that handles all of these needs:
- I think “Database Record” you have hit as a fundamental with Fibery. Particularly well thought out is how you guys have included a few of what you are saying are key attributes - assignee, status - as “Extensions.” I have thought that you guys could build out an extension “library” that could be added as needed, if you want to use an Entity for different purposes.
For example, I’m experimenting with a set up where in CRM and Vendor Management internally, I have both a “company” - the vendor or actual client, and an “account” that’s related. Sometimes we have a Vendor with multiple accounts we need to track separately: Google for Google Ads, Google Analytics, GSuite, etc. It’s not really accurate to just say that’s all “Google,” which you might do in a typical accounting program like Quickbooks. And you don’t need things like “estimate” for those type of entities.
In fact I’ve suggested some more extensions that I hope you’ll consider! In particular, your example of “due date” I think would be very useful, as right now you have to do some work to get the concept of “due date” working, like filtering, etc.
I think another useful would be Checklists:
Your example of “estimates” would be a great extension too, perhaps part of Time Tracking? This is another key piece of Work Management that has specific handling when done well in tools like Jira, Wrike, etc. and is hard to set up for non-developers if you are forced to use Formulas and Automations in nocode tools.
You guys are ahead of Coda/Notion here as they don’t have any concept of the key attributes around these dB records you point out. You have to create your own Due Dates, Status, etc. and generally that means you don’t get good handling of these key Work Management features. As you guys know well, if you were to compare how Asana/Wrike/ClickUp handle due dates vs. Notion & Coda, it’s clear what I’m talking about.
And one more point re: the Database Record assertion: I think you hit on one of the biggest problems with Coda, that Michael also pointed out in Coda vs. Fibery: In Coda, there is a lot of emphasis on Pages/Sections. But these are not Database Records. So you’re stuck with trying to figure out in your schema how to use the Sections/Pages, which it appears Coda is developing fast to emulate Notion’s Pages, and how to use Coda’s dB elements - the tables. That used to give me a real headache! Notion for its part has got this right - like you guys - in that everything is the same type. That said, I think you have them beat - and closer to what you are describing - because in Notion a page often isn’t really a “Database Record,” but more of a Folder.
-
You guys are moving along with Knowledge Hub, as an Entity can be all a Doc needs to be. Most apps have Docs separate from “tasks” or “issues.”
-
You have Dashboards well in hand with Context views - although I could really use some SmartFolder functionality since when I click “show entity of this type in left menu” that menu can get looooong!
What’s particularly intriguing is the “Discussion Room” point. I have spoken with @mdubakov a bit about this, and I believe there is huge potential to get this right - it’s something a lot of apps have not thought through. Things like being able to have a discussion or meeting as an entity of its own, that would in turn relate to other “nodes” around the tool as freely as anything else. With a few more functions, like threaded comments, requirement to “comment” on close, and a couple others that could be added via Extensions (like assignments and workflow), I think you guys would have this 4th need covered.
But I fully agree that how you’ve laid this out to those four purposes. Another thing I’ve done in Fibery, since coming across you guys, is to start to see how superior it is to be able to use an entity for just about anything - Except as a “folder” to group other entities 
per my previous post.
Another example for you: My team used for a few years the Confluence/Jira combo many teams use. It was a constant mental struggle to figure out what goes in Confluence, what goes in Jira. You could relate the two, which was in fact my favorite feature. And the desire to do more relations has led me to search for tools like Fibery that appreciate this need. But in the end, we had a pretty messy set up, with stuff partly in Confluence, partly in Jira, and I always felt that it was hard to distinguish, most of the time, when something should be a Confluence Page, or Jira Issue. You guys have completely solved this already!
Thanks again for the post and eager to see what you publish next on this excellent subject!