🌰 Fibery major conceptual (yet) unsolved problems

This post contains major unsolved problems in Fibery from product side. Some of them are in progress, while most are not and will be in our focus in near future. The list does not includes relatively trivial problems that we know how to solve, like Required Fields or Mobile.

I just want share it to give you a glimpse of what we will be focusing on in 2025. Please note that all these plans are just
 plans. Reality can (and will) correct them.

In Dev: Permissions & Sharing

While we have a conceptual solution and will implement it soon, there is still a lot of work around UI and setup simplification. Also information sharing is still a huge problem, so it is impossible to build public-facing solutions in Fibery like HelpDesk portal or even share views.

In near (Q1-Q2 2025) future we will deliver:

  • Share Entities with Groups
  • Share Databases with Groups
  • Configure access to Users

Some problems has no we well defined solutions (yet):

  • Can’t hide information from Admin (and Private Databases)
  • How to build Service Desks (Feedback Portal)
  • How to share View s

In Dev: Structures in left sidebar

Left menu setup is far from ideal. It does not work well for large companies, spaces and entities can’t be mixed, space setup mode breaks the flow. There is a hope to solve many problems in nearest future. Here is what we want to release in Q1 2025.

  • Nested Spaces (and make Spaces optional, so it will be possible to mix Spaces, Views, Smart Folders on a top level)
  • Separate “My” from “All” in the sidebar and disable DnD for usual users
  • Show Databases in left sidebar and remove Space setup

Near future: Dependency management

Dependencies are important for any complex processes related to projects and product management, so it impedes Fibery adoption in various domains and a show-stopper for some use cases.

We are going to focus on this after major core permissions changes. Likely Q2 2025. It will include at least:

  • Dependencies in domain between entities and some rules to change dates automatically
  • Timeline View dependencies visualisation (and maybe other views as well, like Whiteboard or even Board)

Near future: Multi-relations (Polymorphic)

What is Polymorphic relation?

  • each end of a relation can hold Entities of different Databases.
    Invoice ←(Invoices)——(Paid By)— Client, Partner
  • polymorphic relations can be of any cardinality, including one-to-one:
    User —(User)——(Profile)— Employee, Freelancer, Contact
  • polymorphic relations can include self-relations as well:
    Issue ←(Blocks)——(Depends On)→ Issue, Incident

We’ve added them for Highlights already, and it works well. Next step is to add them to usual databases. This feature is maybe important for Global Databases as well, since we want to link Documents to many different Databases. However, current limitation of 6 entities maybe not good enough.

Next: Global Databases

Some databases are quite generic (global), like Docs, Tasks, Events, Meetings, etc. Global Databases can live in the root Space after Spaces redesign. In most cases they need multi-relations, but we can try to handle it via weak relations (Comments is an example).

Next: Documents as View → Document as Global Database

We’ve made a mistake from the beginning and modelled Document as a View. It was the fast way to do it, but it caused a lot of limitations and problems. Now we have two options to create wikis and people get confused.

We will fix this mistake and make Document a proper database (Global Database).

Other conceptually unsolved problems (but less important
 maybe)

It is unlikely that we will take these problems in 2025, but some improvements are possible here and there.

  • Near-sync communication (Chats, Comments, Thread View, etc)
  • Context empire (smart folders, dynamic filters, etc)
  • Dates as Databases. There are many problems with date as a simple field representation, like lack of grouping, poor visualization, etc. It is quite hard to unify dates concepts, but we have some ideas, like create a special integration that will populate databases like Year, Quarter, Month, Date and use relations to entities and these databases.
19 Likes

Thank you for this post, which is very helpful to spark a potential ongoing high level reflection. Here is my fist suggestion. It is the unromantic version.

Fibery needs more money to make things happen. For that you need to scale effectively and grow its user base. Consider this approach:

Make Fibery Modular

Modular design means breaking the software into separate, independent parts. This setup boosts scalability, speeds up development, and lets users customize workflows to fit their needs.

Benefits:

  • Scalability: Modular architecture allows the system to grow and handle increased load without requiring dramatic changes.

  • Flexibility: By dividing software into modular components, developers create adaptable solutions that can evolve with changing requirements.

  • Agility: Modular architecture enables rapid prototyping and reduced time-to-market, allowing for faster product development.

I think modular permissions, dependencies, and global databases can give Fibery a headstart in becoming scalable.

I don’t understand what it all means :slight_smile:

2 Likes

Here is the logic: Funds for rapid development need to come from more users by prioritizing scalability, which requires a modular architecture.

Fibery needs to focus on modularity, AI workflows, and strategy tools to grow fast and stay competitive.

  1. Modularity for Scalability: Fibery can’t scale effectively without modular features. Permissions, global databases, and dependency management need to be modular so teams can grow and customize without being overwhelmed.
  2. AI Workflows Now: AI is moving too fast to wait. Fibery already has great potential here but needs a better interface to make AI workflows simple and accessible for everyone. This will attract more users and position Fibery as a leader in AI-driven company analysis.
  3. From Operations to Strategy: Fibery isn’t just a company operating system—it has potential as tool for analyzing business models and strategies. That’s a big opportunity to help companies not only run better but also understand how organizations grow fast.

Order of Development:

  • Start with modular permissions and global databases to make Fibery scalable.
  • Integrate a simple AI workflows builder as a priority.
  • Add strategy tools to connect operations with high-level decision-making.

And I added that third point that will help you @mdubakov make Fibery focus its key value on high level strategy using measurable data. Fibery will then be successfully ‘eating its own dogfood’, which is being a strategy machine.

@Yuri_BC

It’s a little hard to read this post, as a lot of this is word soup without much meaning. But if I am understanding what you’re (AI?) is saying.

  1. Ability to turn on/off permissions, global databases, and dependency management. Though I have no idea how you would turn off “dependency management”.
  2. You’d like “AI driven workflows”, not really sure what that means. But maybe you mean things like “Generate a database for an accounting setup at my company, I have different types of clients that I’d like to keep track of invoices with X fields” or something?
  3. “tool for analyzing business models and strategies” again, this means pretty much nothing. You can’t become a tool for analyzing business models? Unless I am not getting what you are saying.

“strategy tools” what are these? Do you have any examples?

Trying hard to see what your suggestions are so I can upvote, but it’s a confusing read.

7 Likes

Gantt for timeline

4 Likes

Great to see that this stuff is still on the roadmap! This is pretty much an exact list of my most desired features (dependency management and polymorphic relations specifically).

3 Likes

@mdubakov really exciting to see my team’s top wants in the roadmap.

Dependency management was biggest thing requested by users that we had to overcome.

Polymorphic relations is the biggest thing we want while making systems, and would make some designs easier to solve for. Not sure how much this complicates your architecture.

Dates as database sounds fantastic, could reduce the setup time for calendar-oriented data

@Yuri_BC
Most folks aren’t going to let AI cook up their model and strategy, and if they do, it’s probably going to include some critical errors and suggest “make it modular, scalable, and put more AI in it”


  1. modular design is fibery’s whole deal
  2. what ‘workflows’ entails is vague -
  3. model analysis is done through views and reports - operational data in the DB, strategic info shown in views, and analysis done in reports , maybe you could explain what’s missing for you without a bot and we will understand :slightly_smiling_face:
4 Likes

This is a great looking tentative roadmap.

I’m excited about the possibility of polymorphic databases, for the most part I’m getting by with generic top level DBs (“Tools”, “Tasks”, “Notes”, “Tags”, “Code Snippets”)

Tags + {{DB}} gives me enough context to find what I need.

I’d be curious to hear more details about what this might look like. Would polymorphic databases allow for shared/composing fields? CRM/People databases come to mind. Every person has an email field, but family may have “birthdate” fields, while client may have more business oriented fields

My only frame of reference is something like Tana’s super tags, where adding supertags can add fields from several different tags to one node.

Unfortunately I mentioned only polymorphic relations, not databases. What you described is even more complex problem and we are not going to solve it next year. While we have it in the deep backlog with several potential solutions, all these solutions are not good


1 Like

I’ve been waiting for this for so long :heart_eyes: :face_holding_back_tears:

2 Likes

I hope 3 more months top and you will have it

2 Likes

This may seem like a small detail, but I believe choosing icons for folders & smart folders will be essential to make the visual order functional here.

I have introduces two Spaces and I think they’ll be standard for all Fibery workspaces I build in the future.

  1. zConfig (or Workspace Config for clients) which is a space that contains global databases like Years, Quarters, Tasks, Task Templates, and databases used like global Enums. This space is visible to all users.
  2. Admin, a space for global databases that have privilege access. like financial reporting dates, Transcripts (since not every call I take should/can be shared with the whole team., etc.
    It sounds like the “root space” is a lot like the first, where all users can see them. Is that a correct understanding?
1 Like

We are considering to remove Folder concept and replace it with Space. Icons for Smart Folders we will add at some point.

1 Like

Not sure, but some things can be in Root Space. For example, Tasks are relevant, but some are too tech to live in root, like Enums, Templates, etc, it is better to keep them in some space as you do

So great to see some of the most important topics (imho) on the roadmap for next year!

Hopefully dependencies will be part of better notifications. I find myself continuing to come back to this old thread where @Oshyan and others lay out in great detail the need for better notifications when I miss a deadline for something. Lack of Work Management features in Fibery (Reminders, Dependencies, Notifications, My Work, etc.) - #54 by webinit. I still find Fibery unintuitive for knowing what I need to work on when. Maybe the new “Home” mentioned here is still coming early next year? :crossed_fingers: :crossed_fingers: :crossed_fingers: "My Work" Dashboard / Assigned Entity Aggregation?

Also for docs as global databases: 1. super excited for this! 2. this is only one of two critical changes for us to use Fibery docs more regularly though, the other being a suggesting mode as described here: A "suggesting" mode for document editing (i.e. multiple document editing "roles") WIthout that, our docs still need to live in Google Docs.

Congrats on all you’ve achieved in 2024 and can’t wait to see what you all release in 2025!

3 Likes

Yep. I come back to check for updates on that thread every month and continue to be disappointed by the lack of notifications, recurrence, and date oriented features.

1 Like

Thanks for sharing, @mdubakov. Helps to set expectations for the big items the next year! :slightly_smiling_face:

I’m very excited about:

Nice! Will require some re-thinking of our setup, but will make things MUCH clearer!

Currently using a <parent> » <nested> nomenclature, which will clean up very nicely! :tada:

We currently have used relationships to model dependencies, which is not ideal. So this will be nice!

While not the presumed holy grail of Database Inheritance, it may simplify some of our relationships. :slightly_smiling_face:

More cleanup, this will be great! :slightly_smiling_face:

Of course, I still have my own list of feature requests and improvement wishes, but I still want to say a HUGE thanks to the FIbery team for an amazing year. The product has improved SO MUCH and gotten SO MUCH more powerful right in front of our eyes.

It’s very much appreciated!
Thanks, wish you all a nice year break and a great 2025! Can’t wait!

6 Likes

Since you are talking about the evolution of Folders into objects that are relatable and have the same traits as other entities in Fibery would be huge, I’d like to bring up the evolution of Views as another “object” in Fibery that I’d really like to see get treatment as first-class citizens. My team uses Folders liberally, and we refer to them when writing in comments and rich text areas, but we can see we could really use the other attributes in Fibery around Folders too - references, even status. That was the main reason behind my request for References to Views as a way to emulate Embedded Db’s in Notion. Views are often what are contained in Folders that we create. I think this is along the lines of your comment as well @helloitse.

Thanks!

5 Likes