Default Permissions - ALLOW or DENY by default?

[keithkelly]

Hi.  We're beginning to set up permissions for Beta users (the first external users we'll bring on) and I'm getting uneasy about our current permission setup. Advice would be appreciated.

To be clear:  As it stands today, ALL USERS MUST BE REGISTERED (via SSO) TO READ/WRITE.  While I'm not sure how that's configured, apparently the default permissions have nothing to do with it. 

Reason for proposed change:

What if we were to spin up a new role in the future, like "StrategicPartner" and forget to set up the community disallowance?  Processes should help prevent this, but Default = Allow just seems reckless.

How would you set it up?  Is there anything else I need to consider?  Now's the time  to tweak it before we get deep.  Are there any benefits of keeping it the way it is now?   What would you do?

[elbranscomb]

I would say that if the majority of your current and future audience should not have read/post at Community level then I'd agree the Default user role should have this set to Deny. Then when you set up a new role that has an increased privilege above default then you can change this as part of the new role. So those are exceptions to the default rather than setting up the deny for every new role you add different to the default. 

For reference, our default role is set to a regular average trusted member. We only have 2 roles which are more restrictive. Sounds like your default is more restrictive with permissions above that being granted by certain roles. 

[MohammedSh]

Hello @keithkelly 

The general best practice is to set permissions to deny by default and use roles to grant access at whatever level/area of the community.

Also, permissions are complex so I suggest you sign up for Communities Product Coaching with our expert.