5 Replies Latest reply on May 9, 2013 5:53 AM by keithr

    Restricting Analyst access to calls assigned to them only

    keithr Specialist

      It is possible to publish analyst specific queries and dashboards to Analysts in webdesk so that they can only see certain calls.  However, if you want to restrict Analysts from viewing certain calls, this is not currently possible due to the "search" bar facility in webdesk.

       

      Even with privileged attributes and data partitioning, if an Analyst uses the search bar in web desk they can view or update calls that they are not associated to (as creator, assignee or raise user)

       

      The reason we require such a feature is that we have contractors who will work on specific calls within LANDesk.  They need to have enough privileges to update calls but we do not want them to have the abilty to view other calls that may have sensitive financial information.  (They should only view financial information pertaining to their own calls)

       

      If anyone has found a way of restricting the calls that return via the search bar for Analysts, I would be interested to know how.

       

      Thanks

        • 1. Re: Restricting Analyst access to calls assigned to them only
          Expert

          You could create a "Note" object for each analyst (I hope you don't have 100) and then they could put their sensitive info into that note.  The different objects could be controlled by a role.  We use "Analysts notes" and control access so that end users can't see the Analyst notes.  You could create "Carl's Notes", add an action "Add Carl Note", and then create a role so only Carl can see the data or the action.  You as the admin will see an action for each analyst but the analysts will only see their one action.  Carl will use "Add Carl's Note" and will only be viewable by Carl, an admin, and managers if you give them access.  Then Jim will use "Add Jim's Note", Beth will use "Add Beth's Note", etc.

           

          Would take some training to teach the analyst to never put sensitive info into a basic description but it would work.

           

          If you are on 7.6 the new dynamic forms would also work for you.  If the analyst that created the incident isn't the creator of the incident, higher level analysts or a manager, hide the description (turn visibility off).  They can add notes, attachments, change assignments, but they won't be able to see the incident.

           

          As far as changing what gets returned in the search bar, that is restricted mostly by knowledge.  I know you can turn off the ability to find incident numbers but it is very handy way to search so I would hate to mess with that.  I think you will find that either separate objects or just not showing the description will solve the problem.

           

          Using 7.6 and the dynamic forms will be a lot easier to implement and will take less maintenance if your analysts change often.  However, your analysts must be using Webaccess.  If you have not moved to Webaccess then you have fewer options as dynamic forms will not work in console.

          • 2. Re: Restricting Analyst access to calls assigned to them only
            Stu McNeill Employee

            Hi,

             

            There is a system in Service Desk you can use called Data Partitioning to limit which records an analyst or end user can access.  See the section from page 26 of the Administrators guide: LANDesk Service Desk Suite 7.6 Administrator.

             

            Thanks

            • 3. Re: Restricting Analyst access to calls assigned to them only
              keithr Specialist

              Hi Stu,

               

              Can you let me know if you have succesfully prevented calls from returning via the search bar in web desk by using data partitioning.  Am testing data partitioing and still an Analyst placed into a customer group with data partitioning enabled can view calls that are not assigned to his/her support group when using the search bar.  Either I have set up data partitioning incorrectly or the search bar in web desk ignores data partitioning.

               

              Here is how I configured data partitioning:

               

              1) Created a customer group called "Contractor Support"

              2) Added my analyst contractor into that customer group and removed him from all support groups

              3) Enabled data partitioning on that support group "contractor Support"

              4) Rebuilt knowledge base, ran an iis reset and restarted both background and knowledge services

               

              I left the default partition attributes as per out of the box, but if I log in as the analyst contractor and use the search bar, I can bring up calls that are not assigned to my "contractor support" group.

               

              In relation to the initial response from Csimpson, unfortunately Analyst defined objects or dynamic forms will not work in this instance since contractors need to see all attributes on the form for calls assigned to themselves.  Also, maintaining permissions for each contractor would be unmanageable from a design point of view in the future if created objects individually for each contracto.  I.E. some contractors will leave and come back later, additional contractors will be added in the future also.  Thanks for responding though.  In other scenarios, your suggestions would work perfectly.

              • 4. Re: Restricting Analyst access to calls assigned to them only
                Stu McNeill Employee

                Hi,

                 

                You also need to turn on partitioning for the object you want to limit access to, ie. Incident.  The steps on pages 27-28 of the Administrator's guide goes through that.

                • 5. Re: Restricting Analyst access to calls assigned to them only
                  keithr Specialist

                  Thanks Stu,

                   

                  I had switched this on at Process level but that does not seem to work as indicated in the manual.  Once I updated it to run at domain level, in this case, on the request object, it worked fine.

                   

                  Thanks again for the pointers, much appreciated.

                   

                  Keith