Problem: Some fields within an entity may need different permissions than others.
E.g., if a Task has a “Due Date” field, this ideally would not be editable by the Assignee - only by a “manager”. But the Assignee will have Editor permission for most everything else in the Task.
A hack might be to use a lookup to a Due Date field that exists elsewhere, but that complicates changing the Due Date for someone who does have permission.
I don’t know when (if ever) field-level permissions might be implemented, but in the meantime, you might consider having an automation that notifies the manager when the Due Date field is updated, so at least he/she can be warned that someone is making changes.
(and the change can be reverted if necessary)
Hi,
We have several databases where we would like to limit visibility to some of our users (in this case our interns and externals who have access to our documentation)… Currently the only solution I see is to create a separate database, however I wondered if there is any option to provide access on a field level.
I’d imagine that by default the fields of an entity would be available based on the entity sharing settings. However, if I have a field ( for example prices of something) that I want to hide for everyone but our managers, then it would be nice to have a “Sharing” option where we can limit access to a set of users or a team/group.
Field level permissions are not on the radar any time soon
You alread know this but just for people who may read this… When you update a field in Fibery it runs in a system mode that doesn’t record who made the change.
A clumsy workaround is to use a submit button that captures an ‘input date’ field value and uses your identity to update a secure date field, if permitted.
I hope that in the future Fibery automatically tags each update with the user’s info, e.g. through a property args.updatedBy
What do you mean by this?
The activity log (for the workspace and for each entity) records whoever updates a field.
yes, but Fibery does not currently expose this user context directly in field-change automations, right?
true, but how does that relate to the text you quoted:
?
Or were you referring to this:
?
It applies to both your and his messages.
Matt says a lookup field to field elsewhere complicates changing the Due Date for someone who does have permission.
You suggested a notification when the field is updated.
The complication is that without user context any corrections or restrictions need to happen after the event.
I gave an extra workaround with an input field plus a secure field, and a button to expose the current user to an automation which either shows or submits.
Then I don’t understand what the problem is.
If you have an automation that notifies someone when a field is changed, it is possible to get the identity of the person who made the change using a formula: User who triggered rule
(and similar is available in buttons: User who clicked button)
Isn’t this exactly what you are asking for:
?
Maybe I am misunderstanding your point 
Wow thats amazing, thank you for pointing that out.
I will test it now…
