The structure developed organically over time and is divided into sites representing different departments. Within each site are projects that are for teams within departments or actual projects being worked on across the entire department. This organizational structure has worked for us but may not work for everyone. I encourage you to let the users direct the organizational structure of the server while also providing guidance in thinking about future growth and changes. We currently do not use nested projects, though a user recently inquired about them. These nested projects further divide and organize workbooks and datasources.
It is at the highest project level that we assign permissions, requiring that the project is locked. We assign permissions to a group, not an individual. The benefit of using groups is that access is managed via Active Directory. This means that Tableau Server admins don’t have to manually manage user access and (hopefully) there is a much larger group of IT professionals that can help manage the Active Directory groups.
When deciding the capabilities to give users, I wanted to start with something simple. Back when I first designed this model I was a new server admin and the previous flow chart of permission evaluation was difficult to understand. Instead, I reviewed the capabilities listed here and decided to specifically choose whether to choose or deny the capability. This seemed to be the clearest path forward.
Over time I have developed a list of rules (that are unbreakable) and guidelines (defaults, that can be modified). They are listed below and available as a pdf using the link at the bottom. I go into much more depth during my conference presentation, so hopefully you can attend!
