1 Reply Latest reply on May 24, 2018 7:02 PM by Brandon Babbitt

    Helping finding a use case for nested Projects...?

    Andrew Clapson

      I was pretty pumped for the introduction of nested Projects in Tableau Server 10.5, since we manage all our permissions by Project - almost without exception, permissions are locked to Project using Active Directory groups (my company has about 1,800 people accessing our Server).


      However I've been disappointed in practice with the restrictions on a locked Project having only other locked Projects within it.


      Unless I'm misunderstanding, this makes nested projects useless for how we manage permissions, if they simply inherit the permissions of their container. What I really wanted, I now realize, is the ability to set up something like this:

      1. Finance (Finance-focused visuals, locked to be accessible to all Users)
        1. Finance - Senior Leadership (reports for executive, accessible to short list of folks)
        2. Finance - Dev (reports under development, viewable only by Finance team's Tableau developers)


      Or something like the above, anyways.

      We have too many people and Projects/Visuals to mess around with unlocked, individual permissions management by Workbook or View.


      Any other opinions on this? Am I totally missing the point here?



        • 1. Re: Helping finding a use case for nested Projects...?
          Brandon Babbitt

          Based on your described use case, it sounds like this would currently require you to keep permissions unlocked to the project, and set group permissions individually at the parent project (and nested project) levels.


          From Permissions in Project Hierarchies:

          The following common scenarios are possible only when you keep the project hierarchy unlocked:

          • You want to create projects for different types of access your team needs for content in child projects. This strategy is described in Configure Projects, Groups, and Permissions for Managed Self-Service, and it requires setting unique permissions on each child project.If you keep permissions unlocked, you can still set permissions at a parent project level that you want all child projects to take by default. And you can use groups to set capabilities explicitly, including denying the Set Permissions capability, so that users cannot set permissions on content they own.


          So in theory, you could set the base permissions on the parent project to allow access to all users in the Finance group, and then on the nested projects, you could choose to grant permissions to only the "Senior Leadership" and "Dev" portions of the Finance group, respectively.


          Hope this helps!