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
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.
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.
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.
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.
