I also have an App User role whose members should only have access to specific OCs based on restrictive conditions — for example, they should only see Company objects they are assigned to:
The issue is that as soon as you define conditional permissions for reading the Company OC for the App User, the Superadmin loses access to that OC — unless it’s explicitly redefined under conditional permissions:
This behavior makes setting up permissions quite confusing and cumbersome. If per-class permissions are ignored once conditional permissions are activated, they should ideally be disabled to avoid confusion.
However, the preferred approach would be for per-class permissions to remain valid by default, and only be overridden when conditional permissions are explicitly defined for a given role and operation.
This is the intended behavior. Checkboxes per object class are not “ignored” — they act as maximum permissions. In other words, they define the upper limit of what can be granted in a condition. You cannot assign a permission through a condition that isn’t already checked. Since they serve a purpose, they cannot be locked.
I do agree that it is not always easy to see what has been configured and therefore when setting up permissions it can be quite cumbersome.
The devs team is informed and I have created an improvement challenge for this topic.
Hi @ulrik! Thanks for clarifying — that makes sense now.
I do still feel that it ends up being a bit of double work when what you actually want to grant is the upper limit, since you have to redefine the same access again under conditional permissions.
Also, I couldn’t find anything in the documentation mentioning that this is the intended behavior before posting here, so it might be worth updating that section to help others avoid the same confusion in the future.
Appreciate the quick response and the improvement challenge being raised!
