<@U019BCGD0QY> and <@U010L66PJ6N> Thank you for your valuable comments!\nRolling back a bit I like option 1 more, it's probably more flexible and future proof. Yet a case can still be made for a more simpler model using option 2 (M-M directly from Role).\nHaving said that, here's some further questions on option 1 including your suggestions\n\u2022 I would prefer to follow the path of least FAB model overriding. That's why I chose to just change the `ViewMenu` model. Also using `obj_type` , `obj_id` is interesting but auto MVC CRUD or auto API CRUD has no way to infer the relation between objects ( probably not a show stopper since we can always custom develop the UI and backend ), but we would loose free constraint integrity from the DB also. So 2.a but using normal SQLAlchemy relations\n\u2022 4.b do you mean using `can_access.dashboard` to refer to a permission that allows to access all dashboards?\n\u2022 By adding a `can_edit` or `can_read_write` permission, we could potentially drop the `owners` concept. I imagine that it's not easy to maintain a list of specific users for each dashboard. Probably better to group users with roles that gives them permission to edit (owners). (We add complexity and also remove complexity)\nNote: Following this new structure we can have data access permissions and dashboard access permissions at the same time and still support the current logic.\nNote: This is a big change, that I think we should eventually make, would love to ear from <@U7HPM7JHL> and <@UH0UPCJVD>