🐠 Fibery product report: February 2026

[mdubakov]

Product: February 2026

In February we did 4 releases with total 470 value points (530 → 820 → 480 → 470 last 4 months).

In this report we will try to focus on strategic themes, not on product areas. Overall, we’ve released many good things in February and tried to focus on our themes with OK success. Still there is area for improvements!

Product scope for the future was corrected. In short, we’ve replaced “Support many use cases” theme with “Make AI Agents happy” theme.

Theme: Granular Access

Done

Allow non-Admins to manage webhooks was done.

In progress

We’ve faced Can’t hide some Fields from certain Users (aka per-Field read permissions) limitation quite a few times recently, and the most common workaround (slicing a DB into two) doesn’t work well because of Lookups.

So we took Show and edit related Entity Fields without a Lookup:

If things go well, this functionality should make our relations even more powerful as well as simplify the life of Architects.

Next

Still waiting for Andrew to get to Configure access to Users…

Theme: Simplify Fibery for architects

Done

We improved import in Introduce optional Field settings in integrations and import and worked on AI-assisted workspace setup mainly in February. Create/Update a Report with AI was released, but not much feedback so far.

Automations rules got previous values access as well: Access previous values for rules in trigger filters, actions (via formula) and markdown templates.

Started or Planned for March

Set context for AI is still in progress and we hope to finalize it in March. It will help architects to work on rules and formulas, create new objects better and forget about Ask/Build mode switcher. There are chances we will complete it indeed in March.

• Set context for Formula Field, update field when iterating with AI
• Support AI context for Automation Rules and Buttons
• New Objects creation from AI Agent unification
• Search Spaces - we need this for AI context
• Set AI context for Space
• Ask/Build mode removal

Redesign Database: Data header it is planned that Ihar will take this quite small feature to reduce architects confusion.

Automatically link entities: operators besides = (>, <, ≠, …) and other auto-linking features. Sergey will lead this feature and area, while Eugene will execute.

AI Integration Agent: Create, test and deploy integration for customer via chat. Now Oleg is working on a crazy idea to let architects create own integrations without code in Fibery. It already works, here is sync with Telegram created with several prompts and iterations. Maybe we will release it in March.

Simpler workspaces toolkit

Done

We’ve completed and finalized validation rules Support Previous field values in validation rules and completed pinned filters Pinned Filters where users can change values. Both features are very valuable.

Started or Planned for March

We will complete several very useful things for entities:

Hide Entity Views based on rules
Specify which Entity View to open for a user or a group
Validation rules on Create events

Customers are happy, but:

I’m thrilled! Both about the hide tabs and the validation rules on create!!! Thank you! I realize it’s a bit cheeky to ask, but I have to — are you also planning to add hide rules for fields? Or for buttons?

If Dima will have time till permissions, we will do Filter and sort relation selectors in Form View.

Theme: Make AI Agents happy

Done

Nothing.

Started or Planned for March

We are taking this theme instead of “many use cases” theme. There will be several areas of immediate improvements.

• Migrate tools from our Agent to MCP. Here we will power up our MCP with many tools and experiment with it in the wild and Support MCP for many sources (n8n, etc) also in scope.
• History API. It will be released as a separate API, as a tool in MCP and there is hope that Trash and Audit Log will work faster as well.
• Make user guide AI-friendly. Now ChatGPT and Claude do not see Fibery User Guide content. We will fix that.
• Better public API guides. Sergey will lead this initiative to its conclusion and we will have better docs in better format for developers (and agents) to use.
• Better search. Here we will focus on Search and Semantic Search improvements. Pavel will start something, then we will see who will join.

Theme: Growth

Done

Introduce themes to support new visual identity. We released warm theme consistent with the new Fibery visual identity and made it default for new users:

The feedback has been (almost) exclusively positive so far:

One would imagine that this did not matter, but honestly as somebody who has always set a warm background in designs, I it. Instant upgrade of my daily experience in Fibery.

—

I love the warm theme! Really looks nice. I often use dark mode but this is also pleasant on the eyes. It’s a fresh, warm look!

In progress

There are a few more things we need to polish to graduate the warm theme from beta and advertise it among the existing users:

• Apply custom theme in vizydrop reports (& import from CSV)
• Apply themes to desktop app
• Adjust color palettes based on theme

Other

This theme contains features that are not part of our strategy. However, for some reason, there are many features here. The reasons are stated below and overall this section should be as empty as possible .

Some features are customer specific, sometimes we want to delight people.

Done

Many people worked on things outside our main themes due to various reasons. Dima did not have work from permissions and had to find something. Eugene is too fast and had time to work on several things in parallel.

• Timeline: improve performance to support lots of items
• Embed Fibery as an iframe into external applications
• Filter by to-many relation count
• Allow to pick multiple values in ‘contains’ filter in case of many-to-many relation
• Batch drag and drop cards on Timeline, Gantt View, Board and List Views
• Entity history for a specific Field
• Empty states on Entity View
• One-Click Copy URL from Table View (List, Board, Timeline too)
• Prettify Form creation modal
• GitHub: sync Projects
• GitLab: Sync milestones from Issues
• Add toggle to show/hide formula data in activity log and entity history

AI Agent. Here we did many things for AI Agent it it was all in scope of our strategy. AI Agent quality improved, it gets mentions now, can access history, etc.

• Stop AI Agent execution
• Set AI context manually via UI control
• Add ability to see history for AI Agent
• AI Agent: Support mentions in rich-text
• Re-design AI Panel

Files. A continuation of files theme, still not done in February.

• More File Unit visualizations on Entity View
• File Unit visualization in Forms

Whiteboard

• Redesign shape toolbar

Started or Planned for March

Rich text product area polishing will continue:

• Improve pasting a markdown content form vs code editor
• Migrate mentions when converting or merging entity
• Reorder rich-text blocks via drag’n’drop and keyboard

Files. We have to finalize this theme.

• File Unit visualizations on Table View
• Sort files
• ? Upload several files/images/videos at once

Make Customer X happier. They create AI reports often but there is no place to show them in Fibery in a good way. Create HTML reports in Smart Agent with Fibery (or custom) styles and Embed View (iFrame View)

Make Customer Y happier. Create personal Folders in Favorites. looks like a quick task for Kostas, that we will do after colossal DnD in rich edit.

Make Customer C happier. Add the ArchiMate shape set.

P.S. Your feedback is welcome!

[RonMakesSystems]

Thanks for sharing these, as always!

@mdubakov

So we took Show and edit related Entity Fields without a Lookup:

This sounds really amazing!! Essentially solving this: Editable Lookup Fields

As well better control over permissions. IE: only show the lookup if you have access to the other entity where that field is from. Opens up a lot of power!! I wonder if this could be set by formula? Get field x if a, and get field y if b. Of course, both fields must return the same type of data. It maybe would also allow going deeper into relations using a single field.

@mdubakov

If Dima will have time till permissions, we will do Filter and sort relation selectors in Form View.

Amazing!! Thank you Dima!

This was a great month, looking forward to the rest March.

[interr0bangr]

Are the following things from your 2026 strategy still on your Q1-Q2 roadmap? Every single one of them would be insanely valuable to us so we’re anxiously waiting.

• Generalize context filters into dynamic values. Greatly simplify context management for views.
• Allow users to create multi-relations (Polymorphic relations). For example, you want to link Document to Project, Epic or Feature, now you have to create three relations, and it is very bad workaround.
• Automatically link entities: operators besides = (>, <, ≠, …). Now we have only = operator and it is not enough for many use cases.
• Better Formulas (combine collections and entities, Convert Text to Number in Formulas, Clear field value in formula, …).

[mdubakov]

@interr0bangr

Generalize context filters into dynamic values. Greatly simplify context management for views.

Gonna start in March

@interr0bangr

Allow users to create multi-relations (Polymorphic relations). For example, you want to link Document to Project, Epic or Feature, now you have to create three relations, and it is very bad workaround.

Q4 in best case scenario

@interr0bangr

Automatically link entities: operators besides = (>, <, ≠, …). Now we have only = operator and it is not enough for many use cases.

Will be started this week.

@interr0bangr

Better Formulas (combine collections and entities, Convert Text to Number in Formulas, Clear field value in formula, …).

Most likely Q3 and Q4

[antoniokov]

@RonMakesSystems

only show the lookup if you have access to the other entity where that field is from.

Yep, this is a part of our thinking!

@RonMakesSystems

I wonder if this could be set by formula? Get field x if a, and get field y if b. Of course, both fields must return the same type of data. It maybe would also allow going deeper into relations using a single field.

For now, it’ll be straightforward one extra level deep without forking. We’ll see what use cases pop up next.

However, it’ll be a tradeoff between flexibility and performance, since those units have to be queried every time user loads a View with them.

[interr0bangr]

@mdubakov

Generalize context filters into dynamic values. Greatly simplify context management for views. - Gonna start in March

Awesome! Any hints as to the scope? I’m kinda hoping some the following might be addressed as part of it:

• Allow entities from the same database to be added to a view at more than one level
• Apply context filtering to all levels of hierarchy in a view, not just the top database
• Fixing the UI on relation context filters where it becomes almost impossible to use if there’s many levels due to how many options are listed.
• In relation views, allow “is this entity” value to used in filtering
• In relation views, allow the “is this entity“ value to be inherited by filters when creating new entities
• Allow dynamic/context filtering on “many-to-many” relationships
• Allow dynamic/context filtering on “to-one” relationships
• Allow “to-one” related databases to be displayed as levels in table/list views
• Allow “to-one” relation to be displayed as “relation views”, not just “compact lists”

[Bronn]

@mdubakov

Automatically link entities: operators besides = (>, <, ≠, …) and other auto-linking features. Sergey will lead this feature and area, while Eugene will execute.

This is going to be huge.

@mdubakov

are you also planning to add hide rules for fields? Or for buttons?

+1, otherwise we will end up with many views with only 1-2 fields difference.

@mdubakov

Filter and sort relation selectors in Form View

Will this be based on what we’ve selected above in the form? Like, we’ve selected the project, so now we can choose a task associated with that project and don’t have to work out which we need. This would solve so many use cases for me because I’m currently having to build stuff out with the caveat of ‘create the entity, but only with these details, ignoring this field that I can’t hide because it’s used in the name formula, then open the entity and now you can fill in that field because it finally has filtering’. Not so user friendly.

---

I also wanted to ask, is smart folder context view still the only currently way to give context to a dashboard? I wanted to use a view for leads/projects so I could pin filters, but I want a dashboard for each, so it’s going to have to be a smart folder instead and with the number of leads and projects we have open at any one time (~400-500), this will get overwhelming quickly (not to mention that we sometimes want to look at the dashboard of a completed project to inform our choices on a current project).

[Chr1sG]

@Bronn

it’s going to have to be a smart folder instead and with the number of leads and projects we have open at any one time (~400-500), this will get overwhelming quickly

Could you use filtering on the smart folder to prevent your sidebar from getting bloated?

[Bronn]

@Chr1sG

Could you use filtering on the smart folder to prevent your sidebar from getting bloated?

There are some people who need to access the dashboard of any and all projects. I considered adding multiple smart folders for different use cases, but I think that just adds to the problem.

[Tommy_Hedley]

@mdubakov

@interr0bangr

Allow users to create multi-relations (Polymorphic relations). For example, you want to link Document to Project, Epic or Feature, now you have to create three relations, and it is very bad workaround.

Q4 in best case scenario

Dang, definitely had my hopes up about this one happening in Q2 . Hopefully we can see it this year, one of my top desired features for a few years now.

[Sev]

@Tommy_Hedley

definitely had my hopes up about this one happening in Q2 . Hopefully we can see it this year, one of my top desired features for a few years now.

100%. Waiting with excitement!

Right now we need junction tables like this theoretic one to connect context to a work item (task):

Where as with Polymorphic Relations, if we need a junction table to hold junction attributes, it would be still much more compact with only one Polymorphic Object field, and if not need for junction attributes, then it would just a a field directly on the Subject Entity.

[B_Sp]

@interr0bangr

Allow users to create multi-relations (Polymorphic relations). For example, you want to link Document to Project, Epic or Feature, now you have to create three relations, and it is very bad workaround.

yes this remains huge for me as well!

[Alex_Rublev]

@mdubakov

We’ve faced Can’t hide some Fields from certain Users (aka per-Field read permissions) limitation quite a few times recently, and the most common workaround (slicing a DB into two) doesn’t work well because of Lookups.

I didn’t quite understand what the issue is with separating the DB and Lookups. I thought this was a valid approach: we keep all fields in one database, and from the second one we only pull in the fields that the user should see via lookups. Could you please clarify?

[antoniokov]

@Alex_Rublev

I didn’t quite understand what the issue is with separating the DB and Lookups. I thought this was a valid approach: we keep all fields in one database, and from the second one we only pull in the fields that the user should see via lookups. Could you please clarify?

Sure!

We regularly recommend slicing a Database into two, a public one and a secret one, and connecting them with an automated one-to-one relation. For example, Projects DB + Project Financials DB or Podcasts DB + Podcast Rates DB.

While this works in terms of pure access, user experience for a manager who has access to both Databases is dreadful. Instead of seeing all the Fields, both public and secret, together on a Project, they have to constantly navigate to the Project Financial to see the rest of the data.

Lookups fail in this scenario because:

• they aren’t editable;

• they don’t respect the permissions of the source entity (everyone can see Revenue that you looked up from a “private” DB via a one-to-one relation).

If none of this is an issue for you, good . You’ll still be able to use Lookups/Formulas in a similar use case.

[myg_ge]

Good, you’ve shared this. I did exactly this trick for my agency workspace where I have internal space (major one with all financials, hr, delivery, etc), contractor space, and client space. The last 2 ones have some shrunk dbs that are 1-1 connected to the core ones.