# May 21, 2026 / đź«Ł Manage users visibility, Send web request action in automations **URL:** \ **Category:** Changelog\ **Created:** [May 21, 2026, 1:50pm UTC](https://community.fibery.io/t/may-21-2026-manage-users-visibility-send-web-request-action-in-automations/10894 "2026-05-21T13:50:49Z")\ **Posts on this page:** 6\ **Page:** 2
**Author:** ![Jonathan1](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/jonathan1/32/10038_2.png) [@Jonathan1](https://community.fibery.io/u/Jonathan1)\ **Post date:** [May 28, 2026, 2:51pm UTC](https://community.fibery.io/t/may-21-2026-manage-users-visibility-send-web-request-action-in-automations/10894/21 "2026-05-28T14:51:54Z")
I think that some improvements should be explored there in order to be better compliant with regulations like the GDPR and to better protect sensitive data. For example, we should be able to “tag” a field as a PII _(Personally Identifiable Information)_. Then every tagged field as PII should only be visible for specific users and can only be exploited on a specific manner. On Salesforce it is possible to categorize every field : [Salesforce Help](https://help.salesforce.com/s/articleView?id=platform.sc_ext_set_up_data_classification.htm&type=5) ![image](https://us1.discourse-cdn.com/flex020/uploads/fibery/original/2X/9/9ee14c5521d6355e40c8f81f37a997181077c399.png) Depending of the categorization of the field, Fibery should automatically hide the information for specific roles. For example, a **Guest** or **Observer** user should not be able to see a PII or a PHI information, if I use the terms of Salesforce. ---
**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:** [May 28, 2026, 3:16pm UTC](https://community.fibery.io/t/may-21-2026-manage-users-visibility-send-web-request-action-in-automations/10894/22 "2026-05-28T15:16:15Z")
If a simple distinction between PII and non-PII is acceptable, then I think the recommendation of two dbs is the way to go. If the categorisation of fields needs to be multi-dimensional, then I can’t think of a reasonable solution unfortunately. ---
**Author:** ![Jonathan1](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/jonathan1/32/10038_2.png) [@Jonathan1](https://community.fibery.io/u/Jonathan1)\ **Post date:** [May 28, 2026, 4:03pm UTC](https://community.fibery.io/t/may-21-2026-manage-users-visibility-send-web-request-action-in-automations/10894/23 "2026-05-28T16:03:27Z")
It adds a complexity layer for architects and Fibery become less user friendly. I’m not only referring to the Users database but for any database. It would be much easier to avoid exposing sensitive data if this functionalities are implemented instead of creating a separate database. Today, the question of data management is critical. Fibery currently have fields with additionnal settings. For example, **People** field have some options : **Allow multiple people** , **Notify people when they’re added** , etc… There could be a new section **DATA COMPLIANCE** _(for example)_, available on every field, with a **Sensitive** and **Categorization** drop-down option. Then, on Fibery Settings, there should be a **Data Compliance** section, on **Workspace** level, where architects can configure who can see what. For every data compliance option, we should be able to select a user, a user group, a trusted domain, etc… Even though you don’t currently have a reasonable solution, I think it’s worth discussing the topic and starting with a simple solution. Inspiration can come later. ---
**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:** [May 28, 2026, 4:44pm UTC](https://community.fibery.io/t/may-21-2026-manage-users-visibility-send-web-request-action-in-automations/10894/24 "2026-05-28T16:44:56Z")
Absolutely agree that it’s a valid use case for field level permissions, but the problem is that technical implementation will be incredibly complex. It took our dev team years of work to implement per-entity access control, and field-level permissions are likely to be at least as complex. I figure it’s fair to set expectations: it’s basically unlikely that it will get implemented any time soon. ---
**Author:** ![helloitse](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/helloitse/32/498_2.png) [@helloitse](https://community.fibery.io/u/helloitse)\ **Post date:** [August 17, 2026, 10:33pm UTC](https://community.fibery.io/t/may-21-2026-manage-users-visibility-send-web-request-action-in-automations/10894/25 "2026-08-17T22:33:41Z")
A builder for the body contents. Like the Notion and [Make.com](http://Make.com) screenshots included in the original feature request or and the feature screenshots referenced in the roadmap. The ability to select existing properties, and use fibery formulas to define the body contents. At present the fibery markdown text block lacks the benefits of a script block and misses the truly no-code experience Notion or Coda packs provide. ---
**Author:** ![helloitse](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/helloitse/32/498_2.png) [@helloitse](https://community.fibery.io/u/helloitse)\ **Post date:** [October 7, 2026, 9:01pm UTC](https://community.fibery.io/t/may-21-2026-manage-users-visibility-send-web-request-action-in-automations/10894/26 "2026-10-07T21:01:23Z")
Revisiting taking external actions from Fibery today. I’ve found that I prefer using scripts to the webhook action after all, since Fibery AI can write the scripts. I don’t have to manually navigate the markdown variable language, especially around calling fields from relations. Noting that the original description for this feature in the roadmap did seem to cover these use cases well, but current implementation makes it harder to leverage, in case poor usage data puts this feature on the chopping block. We do need a webhook action, but the current implementation is not easy to adopt. [Previous page](https://community.fibery.io/t/may-21-2026-manage-users-visibility-send-web-request-action-in-automations/10894.md?page=1)