Ability to root data permissions in custom conditions instead of only roles

Introduction

  • Right now, all data-level permissions are rooted in roles. You assign a permission set to a role or group of roles.
  • That can be problematic at times, and here is an example:

You have a group of team members called “Marketing Director.” You assign a permission to the role “Marketing Director” that limits each MD to only being able to view their own clients (by configuring some simple “user’s can only access records if” logic).

However, there is one particular Marketing Director named Bob, who oversees billing on ALL the accounts and therefore needs to be able to see ALL clients.

However, because there is a permission tied to his role, Marketing Director, Bob will only see his own clients. Because this permission operates at the data level, it cannot be bypassed with a workaround such as using different collection views just for Bob, or similar workarounds.

Which leads me to the feature request:

  • The ability to root permission sets in roles OR in custom conditions.
  • In other words, I create a new permission and rather than tying it to the role Marketing Director, I tie it to a custom condition: User email = bob@email.com.

Objection

  • Obviously a workaround is to create two roles, maybe Marketing Director and Lead Marketing Director. But from a roles standpoint, that’s a bad workaround as you end up with loads of extra roles just to accommodate one simple desired permission.
  • Furthermore, you have to keep both roles “in sync” in terms of where there is commonality in the permissions, only using two roles to manage the points where the logic differs.

Possible Addition

  • The ability to define custom logic for users who should be exempt from role-based permissions. So when you create a new permission, and you tie it to a particular role, or roles, you can also provide custom conditions for which users should be exempt from the role.

In your example Joel, why wouldn’t you just assign Marketing Manager to Bob, and give that role access to ALL clients?

It sounds like they don’t have the exact same role, and thus shouldn’t be squeezed into the same box.

Anytime a request like this comes up this is nearly always the situation.

If there’s some reason why that’s not the case, it would be great to understand it

If you mean Marketing Manager as in a new role, that won’t work well for the reasons I mentioned earlier.

  • In many cases, we have multiple people that have say 85% overlap in their role, responsibilities, and permissions. But for the remaining 15%, one particular person might need differing permissions.
  • Hence the desire for this feature request (especially the “Possible Addition” section) so that you aren’t creating many roles just to cover those use-cases.

It would be great to understand why a new Role won’t work?

If, for example, the new role has most of the same rules as others, then their role can be applied to the existing permission rules, and the ommitted for when permission rules are different.

I appreciate you’re looking for extra flexibility, but we’re always trying to keep complexity down, and understand the root of the problem, where possible

Permissions are already a very powerful and flexible feature, and already incredibly complicated for the average user, so we need to be careful about how we approach adjustments.

I’m not following when you say “…then their role can be applied to the existing permission rules, and then ommitted for when permission rules are different.”

Would you mind using technical language to rephrase that? My apologies if this is really obvious and its just blowing over my head haha.

Of course!

Let’s say there’s 3 tables:

Quotes
Invoices
Customers

All Marketing Managers should only see their customers Quotes and their customers Invoices.

But one Marketing Manager is actually higher ranked and should see all Quotes, but still just their own invoices and Customers, like the other Marketing Managers.
You can assign them a Marketing Admin role.

Then when setting up your permission rules they would look like this:

Quotes

  • Rule 1: Filters quotes by customer, applied to Marketing Managers
  • Rule 2: No quotes filter, applied to Marketing Admins

Invoices

  • Rule 1: Filters invoices by customer, applied to Marketing Managers and Marketing Admins

Customers

  • Rule 1: Filters customers by “owner” applied to Marketing Managers and Marketing Admins

So what you end up with is 2 Roles, which are most of the time the same, but in the exceptional case, different.

Is that not what you have described