5 Replies Latest reply on Dec 10, 2018 2:30 PM by Julian Wigman

    Service Desk 2018.x audit

    losipowicz Rookie

      We're running Service Desk 2018.x.  Having had Service Desk since 2012, we've always been told that there is no audit of who accesses tickets, unless they perform an action and save the window.  Being a medical facility, we would like to know whenever someone accesses a record whether they save it or not.  Has this changed since 2012?  Are there any suggestions of how to accomplish this?

        • 1. Re: Service Desk 2018.x audit
          John Haddad Expert

          Hi Losi,


          better to create roles and partitioning for who can access the tickets.


          each based on his role .


          i don't think there's an audit for who has open ticket without create an update on it .



          • 2. Re: Service Desk 2018.x audit
            losipowicz Rookie

            Thanks for the reply!  I'm not so concerned about who can access the tickets, but more about who actually did.  In other words, if 80 people have the access via a role or partitioning, which of them actually viewed the information?  This is how HIPAA auditors look at it.


            Any ideas?

            • 3. Re: Service Desk 2018.x audit
              Julian Wigman ITSMMVPGroup


              My approach would be to move this sensitive information to a different window based on the main top level business object ( eg Incident) and link this to a “windowed” action created in process designer via a window view rule.


              You would still have all of the fields on the main window at creation (“new”) BUT not on the view/update main window; create NEW and UPDATE. windows for the top level object and link them to NEW and UPDATE window view rules.


              If you need to be able to edit the sensitive data then create another ghost window similar to the view-only one but with read/write fields on the window. 


              If you want to be clever you can get away with only action but with dynamic window that is readonly or read/write depending on the current user accessing but keeping separate “View Details” and “Update Details” actions ( hey i just made up an example name) means you can privilege each out to groups/roles but more importantly you should be able to AUDIT who uses the view action in the audit trail because they clicked that action.


              Hope my ramblings give you some ideas to test.



              MarXtar Ltd

              • 4. Re: Service Desk 2018.x audit
                rmitchell Rookie

                As a follow up to the original question, would this action make an entry in the History Column that, when clicked, would open the "ghost" window and not record who opened it (much the same as if a note is entered it can be seen by clicking on it from the History panel)?

                • 5. Re: Service Desk 2018.x audit
                  Julian Wigman ITSMMVPGroup



                  I think the trick here is to make the Action a process action rather than an optional Action.


                  Pass the manual “view” action onto a dummy status followed immediately by a precondition that checks you are at that status, followed by a “move on” automatic action to take you back to the original status.  I think that then when you close the view window it will pass through this new transitory status and fool the audit trail into logging for you.


                  Do a quick test to try it out maybe.



                  MarXtar Ltd

                  1 of 1 people found this helpful