Al Boyle we understand the painpoint and we revamping our roles functionality with better user experience to provide clarity in the information. For instances, permissions will be provided in detail such as view, update, delete & publish. So when the user clicks on delete, automatically view, update will be automatically enabled.

The visual representation of this, once released will clarify your doubts as well Shawn Wilson , however everything represents the entire project with billing. and if we expand the line the entire UX will be filled with words and that would actually be too much of cognitive process to consume by any user. Hence we try to keep it in few precise words.

Thanks for your understanding and patience Shawn Wilson, Al Boyle

We've had a series of calls with Support to try to clarify Roles, their impacts on areas of the tool, their place in the overall hierarchy (Roles versus Team Accounts versus Permissions, etc.).

-What impact does toggling something on or off have on which application areas?

-Which settings are dependent upon each other?

-Which settings override others? For example, we now understand the permission granting the greatest access governs.

So--if I'm remembering this correctly--if your role allows something your team account doesn't, the user will have the role permission level.

It'd be wonderful to understand how the roles, permissions, and settings do and don't coordinate with each other through the tool (Portal, Site, versions, etc.).