User Permissions

[Jessica_Kammere]

Hi there! I know that advanced user permissions are something the developers are working towards, and I saw that providing examples of our use cases can be very helpful for that purpose. Hopefully I’m posting in the right place?

I am the development director of a small team (13) of indie game developers. We use airtable to keep track of tasks, meetings & milestones, and developer statistics such as average hour estimate accuracy. This is the second team I have used airtable with. Most of them have not used airtable before and I have noticed some issues while onboarding them - there’s a direct relationship between how robust my setup is and how much bloat there is that confuses them.
I am most concerned with view access for fields. While it is possible to hide fields in certain views, they are still visible when the record is opened. I would love three levels of viewing access for fields - displayed on a card and when the record is opened, displayed only when the record is opened, and not displayed at all.
This is because I make high use of linked records, formulas, rollup, etc. Many of these fields don’t really “read” to the human eye, and having them commingled with important fields like ‘Logged Hours’ or ‘Priority’ confuses my developers. Of course I order the fields so that these are always at the bottom, and in a grid view it’s not an issue - but for task management, kanban is the ideal view, and these can only be edited when you open the record.

This issue could also be mitigated with more robust available formulas, reducing the need for lots of fields that essentially perform filter functions.

[BillFrench]

Welcome to the forum Jessica!

Jessica_Kammerer:

how much bloat there is that confuses them.

I could not agree more and would add that field bloat is typically created because other features (or lack thereof, or for whatever reason) force us to create layers of additional field-level logic to make our solutions viable. These fields - in some cases - become a distraction to users and such exposure may actually reduce the reliability of the solution.

In my view, there are three dimensions to the issue of field bloat; (i) the additional fields themselves, (ii) the need to suppress visibility of certain fields, and (iii) the need to lock down certain fields regardless of visibility attributes.

As to (i), if there are fewer extraneous fields needed to achieve a solution, the problem begins to remedy itself to a degree. But (ii) and (iii) play critical roles in crafting solutions that are perceived as simple and elegant for users.

[Desmond_Beatty]

BillFrench:

crafting solutions that are perceived as simple and elegant for users.

Quite… the bloat is killing us! I got this from the top man only yesterday “I…will not think twice about going back to a manual process that I know works.”

Sad to say, the process is there but the bloat and lack of granular profile / permission / role control of view lists, view content, table visibility, etc, etc, etc… makes it effectively unusable “in anger” ie in the real world situation.

[Michael_Skelly]

I’d be remiss if I didn’t mention: this is one of the main things people use Stacker for – to show different people completely different views of your data. We even support different views for different user roles. (Disclosure: I built it!)

[Desmond_Beatty]

Hi Michael
The Airtable views are fine, we just want to eliminate the bloat and control access.
I will take a look at stacker to see if it gives the precision of U/X (U/I, Process and Data) we are looking for.
Thanks, Desmond
PS Any further pointers, worked examples appreciated.