User Tables and Custom Roles for Workflow Application

I have come across some great discussions regarding the use of user tables such as this:

At the same time I have come across discussions that mention the use of slices to narrow down data is a ‘bad’ idea because someone that is savvy can still get access to the whole data set.

My use case is an application that takes a batch of documents, they are created at the ‘Clerical’ role level, then they are passed to an ‘Assignment’ role level, then ‘Technician’ role, and finally ‘Finalization’ role where the batch is assigned a ‘Complete’ status.

I am still early enough in design that things can be changed around. However I was planning a column for Status which would set at which role level the batch is at the moment until ‘Completion’ as well as who it is assigned to in each of the processes.

Ultimately there will be a view that anyone can ‘read’ all rows for the batch table, then a view of your current assigned batches depending on role, status, and your email. I had planned on using slices and allowing certain actions within the slices like ‘add, update, delete, read’ to specific roles and status items along with specific user actions and workflows.

I was hoping someone might have example applications they could point me towards that are similar in nature to what I am trying to accomplish?
Also some clarification when to apply security filters to the table itself vs using slices to filter data and to allow ‘crud’ actions to slices/full table would be helpful?

In my opinion, if you have confidential data that some users should not be able to access, then a security filter on the table is recommended. This filter will be applied at the server and will ensure that the excluded rows will not be loaded on the device / browser, which will also improve performance.

You approach for the implementation in fine, I have done something similar and it works. I used a RBAC (Role Based Access Control) method where : (1) A user (email) has assigned role(s), (2) A role has a set ot permissions, (3) operations (opening a view, executing an action, table changes - add, delete, update, column edits/show) require a permission. This is very flexible. You can have some slices/views that allow reading all rows, and some more restrictive views for updates. You can use slices to limit the available actions, and also the condition on an action checks for the permission. For this I only use custom views and actions, no system generated views and actions.

1 Like