# October 2, 2025 / 🥗 Bunch of usability improvements

**URL:** <https://community.fibery.io/t/october-2-2025-bunch-of-usability-improvements/9722>\
**Category:** Changelog\
**Created:** [October 2, 2025, 1:44pm UTC](https://community.fibery.io/t/october-2-2025-bunch-of-usability-improvements/9722 "2025-10-02T13:44:14Z")\
**Posts on this page:** 13\
**Page:** 2

<div class="post-metadata">

**Author:** ![Sev](https://avatars.discourse-cdn.com/v4/letter/s/90db22/32.png) [@Sev](https://community.fibery.io/u/Sev)\
**Post date:** [October 3, 2025, 12:33pm UTC](https://community.fibery.io/t/october-2-2025-bunch-of-usability-improvements/9722/21 "2025-10-03T12:33:49Z")

</div>

> [@Chr1sG](#):
>
> When you apply a relation filter in one picker, it will work for all pickers on the UI of the same type (compact).
> 
> It is true though that the filter is a UI filter, not a filter defined at the relation field level.

Thanks. Yes, it works for the time being as is. If a future improvement allowed the relation to be filtered and sorted on the relation field definition level, the modelling/architecture UX would be better. 🤞

> [@helloitse](#):
>
> Not in my case. If it’s a matter of workflow, there are times when I the admin only want to link existing entities without the option to create a new one

I see your point, but admins generally are more cautious about causing data fragmentation and integrity violations, than non-admins. 🙂

---

<div class="post-metadata">

**Author:** ![Wilco\_Boode](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/wilco_boode/32/9985_2.png) [@Wilco\_Boode](https://community.fibery.io/u/Wilco_Boode)\
**Post date:** [October 3, 2025, 1:13pm UTC](https://community.fibery.io/t/october-2-2025-bunch-of-usability-improvements/9722/22 "2025-10-03T13:13:22Z")

</div>

I see the point here, thing is we have project managers who are allowed to create new “teams” as we call them. However, we had several encounters where these project managers accidentally made new teams while they tried to link an existing one to their projects.

This is the same with projects, we had it happen that a project was created by accident, this immediately triggered a bunch of rules (like creating teams and sprints), and undoing that mistake was quite annoying.

Coming back to @Chr1sG option of permissions. Is it possible for people to view all data but not create new ones? I could not find this option, because even the lowest (submitter) access level can still create entities. If not then how would we block users from creating new entities?

One of our examples:

We have a database with Equipment, and a database with Bookings  
If people create a new booking, then they should only be allowed to link entities that already exist. Ideally creating equipment would only be done by users with specific rights (like me as an admin), but i still want all users to see all the available equipment and be able to use all equipment in a new booking.

At the moment, when creating a booking or editing the equipment field it happens quite regularly that users accidentally create a new piece of equipment that does not exist because the Create option cannot be disabled.

---

<div class="post-metadata">

**Author:** ![Chr1sG](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/chr1sg/32/3941_2.png) [@Chr1sG](https://community.fibery.io/u/Chr1sG)\
**Post date:** [October 3, 2025, 1:43pm UTC](https://community.fibery.io/t/october-2-2025-bunch-of-usability-improvements/9722/23 "2025-10-03T13:43:45Z")

</div>

> [@Wilco\_Boode](#):
>
> Coming back to @Chr1sG option of permissions. Is it possible for people to view all data but not create new ones? I could not find this option, because even the lowest (submitter) access level can still create entities. If not then how would we block users from creating new entities?

At the database level, you can make someone a Viewer (or Commenter) and they will not be able to create new entities of that type.

---

<div class="post-metadata">

**Author:** ![Wilco\_Boode](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/wilco_boode/32/9985_2.png) [@Wilco\_Boode](https://community.fibery.io/u/Wilco_Boode)\
**Post date:** [October 3, 2025, 2:18pm UTC](https://community.fibery.io/t/october-2-2025-bunch-of-usability-improvements/9722/24 "2025-10-03T14:18:06Z")

</div>

Right, i forgot about that.  
The access rights can be pretty confusing, as they stack, but not in this case (where submitters can submit, but the level above that cannot submit. My mistake.

For the equipment that would indeed solve the issue

---

<div class="post-metadata">

**Author:** ![AdVhPkgKad](https://avatars.discourse-cdn.com/v4/letter/a/7993a0/32.png) [@AdVhPkgKad](https://community.fibery.io/u/AdVhPkgKad)\
**Post date:** [October 5, 2025, 11:05pm UTC](https://community.fibery.io/t/october-2-2025-bunch-of-usability-improvements/9722/25 "2025-10-05T23:05:41Z")

</div>

Conditionally hiding entity-level views seems to be the go here (e.g., hide a view unless the user is in group A, or hide views if the entity is in a particular workflow stage)

I also think changing default view depending on who is entering, where from, or what stage it is in, would go a long way to making true workflow systems. I could see it being used as a multi-stage form, where each stage is only editable to a particular group (say an approval process that goes through multiple departments)

---

<div class="post-metadata">

**Author:** ![Chr1sG](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/chr1sg/32/3941_2.png) [@Chr1sG](https://community.fibery.io/u/Chr1sG)\
**Post date:** [October 6, 2025, 6:51am UTC](https://community.fibery.io/t/october-2-2025-bunch-of-usability-improvements/9722/26 "2025-10-06T06:51:55Z")

</div>

> [@AdVhPkgKad](#):
>
> changing default view depending on … what stage it is in

That is already possible: [September 18, 2025 / ⚔️ Specify which Entity View to open based on some field value](https://community.fibery.io/t/september-18-2025-specify-which-entity-view-to-open-based-on-some-field-value/9616)

---

<div class="post-metadata">

**Author:** ![Chr1sG](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/chr1sg/32/3941_2.png) [@Chr1sG](https://community.fibery.io/u/Chr1sG)\
**Post date:** [October 6, 2025, 6:55am UTC](https://community.fibery.io/t/october-2-2025-bunch-of-usability-improvements/9722/27 "2025-10-06T06:55:53Z")

</div>

> [@AdVhPkgKad](#):
>
> where each stage is only editable to a particular group

What do you mean by ‘each stage is only editable to a particular group’?

If you mean that the permissions for who can modify an entity change over its lifetime automatically, then this is already possible. You can do this by having a field which links to the people (or groups) who should be able to edit the entity, and then use [automatic sharing](https://the.fibery.io/@public/User_Guide/Guide/Automatically-Share-Entities-via-People-Field-327).  
The field’s value can be set using a formula, or via automation rules.

---

<div class="post-metadata">

**Author:** ![Eren\_Turgut](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/eren_turgut/32/4425_2.png) [@Eren\_Turgut](https://community.fibery.io/u/Eren_Turgut)\
**Post date:** [October 6, 2025, 7:35am UTC](https://community.fibery.io/t/october-2-2025-bunch-of-usability-improvements/9722/28 "2025-10-06T07:35:06Z")

</div>

~~There still seems to be a limit on how much can be imported with CSV import at once.  
The “We support CSV up to 50MB” seems misleading, if it actually only imports about a quarter of a 1.5 MB, 10k rows file (no warning before or after..).~~

Also, I still have issues of dates importing wrong:

I have dd.mm.yyyy format, and I made sure that first row data has values in date columns which cannot be mm.dd.yyyy (e.g. 24.09.2025). Still, dates are completely messed up.. Testing again now.

Edit:

Importing 10k rows worked on second try, date format still a minor issue but easily fixed by changing date fields in import CSV file to US style mm.dd.yyyy

---

<div class="post-metadata">

**Author:** ![RonMakesSystems](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/ronmakessystems/32/14122_2.png) [@RonMakesSystems](https://community.fibery.io/u/RonMakesSystems)\
**Post date:** [October 6, 2025, 7:41am UTC](https://community.fibery.io/t/october-2-2025-bunch-of-usability-improvements/9722/29 "2025-10-06T07:41:15Z")

</div>

> [@Eren\_Turgut](#):
>
> At least a warning that not all data can or could be imported would be good.

I’ve imported a csv with 300,000 records… so I’m not sure where the limit lies with what you’re importing. Might be a bug?

---

<div class="post-metadata">

**Author:** ![Eren\_Turgut](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/eren_turgut/32/4425_2.png) [@Eren\_Turgut](https://community.fibery.io/u/Eren_Turgut)\
**Post date:** [October 6, 2025, 7:47am UTC](https://community.fibery.io/t/october-2-2025-bunch-of-usability-improvements/9722/30 "2025-10-06T07:47:29Z")

</div>

Indeed it did work this time!

I think it was last Thursday when it didn’t, might have been a bug.

And I was able to easily fix the date issue by changing the date format to US-style mm.dd.yyyy in the import file and re-importing with the update existing entities value’s by ID matching, love it!

---

<div class="post-metadata">

**Author:** ![Eva\_Folch](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/eva_folch/32/11814_2.png) [@Eva\_Folch](https://community.fibery.io/u/Eva_Folch)\
**Post date:** [October 6, 2025, 9:18am UTC](https://community.fibery.io/t/october-2-2025-bunch-of-usability-improvements/9722/31 "2025-10-06T09:18:31Z")

</div>

I also had a lot of problems with dates when importing, and to me, it worked only importing dates as a text, and then coping the whole column to the date column.

---

<div class="post-metadata">

**Author:** ![mdubakov](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/mdubakov/32/10_2.png) [@mdubakov](https://community.fibery.io/u/mdubakov)\
**Post date:** [March 5, 2026, 1:13pm UTC](https://community.fibery.io/t/october-2-2025-bunch-of-usability-improvements/9722/32 "2026-03-05T13:13:06Z")

</div>

> [@timothy](#):
>
> Rules would be great to show tabs only to certain people/roles/scenarios  
> (big +1 for that functionality!! – it would be huge), but that’s a  
> separate functionality.

Released today

> [@March 5, 2026 / see\_no\_evil\_monkey Hide Entity Views with rules, Specify which Entity View to open by default for a user, Validation rules on Create](https://community.fibery.io/t/march-5-2026-hide-entity-views-with-rules-specify-which-entity-view-to-open-by-default-for-a-user-validation-rules-on-create/10491):
>
> see_no_evil_monkey Hide Entity Views based on rules You can now hide specific Entity Views based on rules. This allows you to control which views are visible depending on logged user fields values or entity fields values. To enable Hide Entity View rules, click Views on entity view → … near view name → Set up rules. In many setups, the same entity is used by different teams and across different workflow stages. Over time this leads to problems like: too many tabs on an entity, Views…

---

<div class="post-metadata">

**Author:** ![timothy](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/timothy/32/11812_2.png) [@timothy](https://community.fibery.io/u/timothy)\
**Post date:** [March 5, 2026, 2:48pm UTC](https://community.fibery.io/t/october-2-2025-bunch-of-usability-improvements/9722/33 "2026-03-05T14:48:30Z")

</div>

Wow! This is amazing. THANK YOU!

[Previous page](https://community.fibery.io/t/october-2-2025-bunch-of-usability-improvements/9722.md?page=1)
