4 Replies Latest reply on Dec 7, 2018 7:58 AM by Per Strid

    Permissions

    Per Strid

      Hi all!

       

      I have always been working by myself or in organisations where everything is open to everyone. This makes me confused when it comes to permissions.

       

      Now I have a client where we need to set up restrictions for the data, and to me in a straight forward but nevertheless odd (?) way. I have read everything I come across, but I am still not sure I can see what I want to achieve.

       

      Top level should see everything in bits and bytes.

      Region managers should see detailed data about sales in their region, and top level for the country and other regions.

      Store managers should see detailed data for their store, and top level information about other stores, regions and the country.

      Employees should see detailed sales about themselves, and top level information about the store, other stores, regions and the country. They should also see average sales by employee from their own store upwards.

       

      How should I approach?

       

      Best regards!

      Pelle

        • 1. Re: Permissions
          Sasha Hanna

          Hi Pelle,

          Could you elaborate a little on the content? Is all of this feeding from a single datasource or a single workbook?

          Cheers,

          Sasha

          • 2. Re: Permissions
            Per Strid

            Thanks Sasha!

             

            It's a single data source but multiple workbooks.

            My understanding is that the row level is easy to achieve with a security table that I join. The challenge (?) is to give permissions to the aggregations, so that a single sales person can see the total sums, average numbers per sales person etc.

            I wonder if that is possible to do in a single data source?

             

            Clear as mud...?

             

            /Pelle

            • 3. Re: Permissions
              Sasha Hanna

              Great that's easier to design a security model. Indeed row level security using a join to marry up your user base against your data will be the automatic way.

               

              The tricky part comes for the top level aggregations  (by region, store and country) you could create rows of data for these aggregations and make those available for the corresponding user base. An alternative could be to create those aggregations as separate data sources for individual worksheets within a dashboard, and manage permissions for those at "view level". The latter will on only work with projects that are not "locked" so permissions are not inherited from the project but individually set.

               

              Let me know if this helps or you need more clarification.

               

              Cheers,

              Sasha

              1 of 1 people found this helpful
              • 4. Re: Permissions
                Per Strid

                Thanks Sasha!

                 

                Sorry for taking so long.

                I think I get the concept.

                 

                Best regards!

                /Pelle