The ability to have permissions limited to own records (e.g., records created by the logged-in user) vs all records within an app or workspace would be great. The use case would be to have a single app containing semi-private information.
For example, a Leave Request app where all users can submit their own leave request records, and view records they’ve previously created, but only users in the HR group can see records created by all users.
Another example would be an IT Tickets app where all users can see records they have created but only users in the IT group could see records created by all users.
The current access options are:
Full access
Can share
Can edit
No access
This feature request would expand those options to:
This is a great idea, and similar to your post regarding field level permissions. I think the challenge here is how to define what “own records” mean. You mean it as the records the user has created, however, think of the numerous situations where Automations are creating items, and the creator would be the App itself, therefore, they would not be counted in here.
However, if you expand further on the “role” based architecture I commented onto the other ticket, you could achieve this still. You could go so far as to create a “role” for each user, and then use Automations (and the API, hopefully) to assign an item to a “role”, and in the case of say, a leave request, you could assign the role of the individual who submitted it, plus their manager.
If there was a way to dictate who had access to what records by a member field at the item, that would be great, but I think this is still very limiting, having a true role based architecture would be better.
Working around this issue leads to excessive work and frustration. I attempted to create a time tracking, holiday, and sick leave application for employees as a self-service tool.
Due to the lack of record-level access control in the app, I followed this approach: Create records in a variable app. I tried giving each user their own workspace with individual apps and records.
However, this method fails when aggregating data via calculations. It results in overly complex calculations with links to multiple databases, making it difficult to differentiate records (since the field name in a calculation field doesn’t indicate the app name).
Moreover, all calculations in the central database need to reference every field in each app, which is highly inefficient.