This is a public Idea Center  publicRSS

Idea

    75 liked this

    [In Development] Audit log does not provide enough Details
    Idea posted June 7, 2013 by Ronald HilemanWhiz, last edited January 31, 2018 by Vimal ChopraApprentice, tagged Agent Desktop, Reporting, System Admin and Configuration 
    1103 Views, 36 Comments
    Title:
    [In Development] Audit log does not provide enough Details
    User Story / Description:

    We would like to be able to see what field(s) were edited and possibly the before and after values of these fields when an incident is edited.  Currently, we only have the message, "Edit"   and "Edited from : Incident Editor".

    The transactions table only has queue and status information in the attributes.

     

    We would like to know what field(s) were actually edited/modified.

    Thanks.

    Comment

    • Baxter

      I'd certainly like to see the transactions audit log reporting extended to cover edits to Mailbox, Disposition, Product, Category and also the incident's Contact.

      The ability to report on these would help us a lot in troubleshooting the cause of "bad data" - incorrect values selected - as we'd be able to see if the incorrect value was set by an agent not following best practice or by a mistake in business or workspace rules.

    • Colby Ross

      This would be a great add to the system!

    • Stephen Pickett

      Can we get an update on this please? It will be critical for proper implementation of GDPR from May 2018 onwards which is basically mandatory to all organisations - that's ALL of your customers and partners that will be needing this, and as previously mentioned your competitors are already doing this so it will be even more challenging for us to position Oracle Service Cloud above them!

    • Kincaid

      Agreed, more information is almost always better...but field tracking needs vary from biz to biz.

      Understanding that tracking additional details at the user/ticket transactions level may add heft to the db...it may also be worth considering to give admin's & architects the power to choose/config which incident field updates to track at that audit-able level of granularity....be they out of box standard fields (like queue & status), custom fields and/or incident attrs.

      -k

    • santhosh xavier

      Any update on this?

    • Stephen Pickett

      Chasing an update...

    • Stephen Pickett

      Can someone update us on this please? We are in the throes of preparing for GDPR and need to know what is happening with this.

    • Stephen Pickett

      Chasing an update again. Please can someone escalate this to senior management, this is critical.

    • eileen neulinger

      We would also like to have the attachment activity recorded in the log as to what user attached the file.

    • Pramod Vasudeva Murthy

      Need this enabled in next release, please.

      ~VIP

    • Marc Grant

      This is also something that's come out of our GDPR external review. Would be good to have a response from Oracle on this thread.

    • Steve Fangman

      Hello Marc.  My team is evaluating GDPR requirements.  Would you share why the level of logging has a relationship to GDPR?  Which control(s) were at risk according to your external review?

    • Neil

      A massive +1 from me! It's amazing that this isn't already present in the product, in my opinion.

      The 'audit log' is next to useless. All it tells us that Joe Doe did 'something' at 1730 on 21/09/17. It's the 'something' that we need much more detail of.

    • Corbin Midgley

      Any updates? We REALLY want this.

    • Baxter

      Hi Steve,

      Answering the question you addressed to Marc - within our company, GDPR requirement “The controller should be able to identify all those recipients to whom personal data has been disclosed” is being interpreted as meaning we need an audit log of any time a standard or custom object field which contains personal data is viewed or edited. This could be by console users during the course of handling an incident, when they run a report (we are particularly interested if they exported that information) and also I guess customers logged into customer portal viewing a report of their incident history.

      Kincaid's suggestion above about allowing admins to choose which fields to track at greater granularity in an enhanced audit log would seem to be a possible solution to that.

      However, I’m aware that requiring record views to be included in this desired enhanced audit log - in addition to edits -  is stretching the scope of the original user story for this idea. I don’t want to derail this thread if this is not a requirement from others, so would be happy to give more details if needed and continue offline, you could get in touch with me via our client success manager Ajay Joshi who is already aware of our need for this.