# 😛 February 5, 2026 / Pinned Filters where users can change values, Previous field values in validation rules **URL:** \ **Category:** Changelog\ **Created:** [February 5, 2026, 2:16pm UTC](https://community.fibery.io/t/february-5-2026-pinned-filters-where-users-can-change-values-previous-field-values-in-validation-rules/10356 "2026-02-05T14:16:21Z")\ **Posts on this page:** 1\ **Showing post:** 5
**Author:** ![interr0bangr](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/interr0bangr/32/8089_2.png) [@interr0bangr](https://community.fibery.io/u/interr0bangr)\ **Post date:** [February 5, 2026, 2:57pm UTC](https://community.fibery.io/t/february-5-2026-pinned-filters-where-users-can-change-values-previous-field-values-in-validation-rules/10356/5 "2026-02-05T14:57:01Z")
Great week, appreciate the improvements to Validation Rules and Pinned Filters. Is there a plan to allow pinned filter groups to be handled in a similar way, where maybe the multiple fields would vertically stack? > [@mdubakov](#): > > Integration & Import: specify display options for Number, Percent and Money fields [Could you please increase the number of characters for the unit labels?](https://community.fibery.io/t/remove-or-at-least-increase-unit-label-character-limits/5849) 5 is way too limiting, especially since often one of the characters usually needs to be an “s” to handle cases where there’s more than one unit. For example, instead of saying “months” we have to say either “mons” (weird) or “mnths” (also weird and ugly) or “month” (awkward since the value is usually \> 1). We also use something called “points”, and have to either write it as “pts” (which some people don’t understand and interpret as “parts”) or “point” (again, awkward for plurals). Ideally there wouldn’t even be a limit, but even giving us 1 more character to work with would make such a difference and I assume would be super easy to do! --- _[View the full topic](https://community.fibery.io/t/february-5-2026-pinned-filters-where-users-can-change-values-previous-field-values-in-validation-rules/10356)._