Just about to share an entity externally for the first time when I found out that its not possible to hide specific fields on a Task. Here is an example:
Enabling sharing for this one is quick and easy. Nice! However I noticed all the internal fields we use are shared as well. Some of them - I dont mind - others: Time spent on the task, energy required, etc. - should not be shared with the client. I asked Fibery AI and it told me that there was no way to hide fields for the general Viewer role and I should instead try to create another view. Bummer!
Is there another way here? If not, this is a feature I really need because it can happen quite a lot that I need to share small things once, not setup a whole guest dashboard. Similar to just sharing a Google Doc with comment access which is always quick and easy for rapid communication.
However, unfortunately, at this moment both tabs would be visible. It’s on the roadmap to being able to hide tabs based on rules - so you could manage visibility per certain criteria.
Field level permissions are not possible in Fibery (and there are no plans for adding them).
Also note that even if you configure what fields users can (and cannot) see on entity view, this is not the same as strict access control - any user can create a data view in their personal space, and then show any/all fields for entities to which they have viewer access (plus they could also use API calls to retrieve all entity data)
Can you elaborate on the reason for not adding them? To me it seems like a pretty obvious use case to share a single entity with an external guest without them looking at all the data available?
Or is there an actual better way that I don’t see?
If this feature is never coming I’ll have to make a plan to structure a good chunk of my spaces differently
It took our tech team more than 3 years to deliver granular per-entity permissions, and so the idea of delivering field-level permissions probably terrifies them!!!
But seriously, there’s currently not enough use cases for field-level access (which can’t be solved in other ways) to justify taking resources away from other things we hope to work on.
FWIW, you may be able to achieve something equivalent to field level permissions for editing using validation rules, e.g. block any changes to field X if the user who attempts the change is not a member of Group A
And when it comes to hiding data completely, we generally recommend splitting a database in two dbs (e.g. Basic + Sensitive) whereby you can put fields that should not be viewable for all in the second db, leaving the first db for things you don’t mind sharing.
This solution doesn’t scale to complex field-level use cases, e.g. if there are multiple combinations of who-can-see-what, but it covers a lot of people’s needs, based on the conversations we have had with users.
