What is the Access log API?

Angeheftet

10 Kommentare

  • Offizieller Kommentar
    Caroline Kello
    Zendesk Product Manager

    Currently known limitations of the EAP

    • A large part of our frontend uses a tool called GraphQL. For the purposes of this EAP it  means that the URL path is obfuscated and we don’t know what was accessed as part of the request an agent made. You will see this /graphql path in some of the URLs. 
    • If your account moves pods at any point during this beta, you’ll lose access to the information and events that were created when you were on the old pod will not be copied over. 
    • There are still some parts of the product that we can’t gather information from; Explore, Sell etc. 

     

  • Caroline Kello
    Zendesk Product Manager

    Added a new bullet point to the Additional information section that calls out that the API supports cursor-based pagination.

    1
  • Dan Cooper
    Community Moderator

    Would this also show us when Zendesk employees access our data via account assumption or otherwise?

    1
  • Caroline Kello
    Zendesk Product Manager

    Hi Dan, apologies for the delayed response. I've not tested this myself but I assume that as a Zendesk employee accesses the account as another user, any action they take is logged as being taken by the user they accessed as. This is true for how events are captured in the Audit log today, and should also be true for the Access log. 

    0
  • Chester Hansen

    Hi Caroline,

     

    I have a question about /graphql results. 

    I see that there is a "graphql" property when that is the end point that is being accessed. This shows the query, name, type, and variable. which is great. However, is there a way to see the result of the query? For further context, we plan to pipe the logs into a longterm storage with the ability to query and filter later if needed so we have access longer than the 90 days of Zendesk. We are wanting to have a record of when an agent access customer data. getting just a query, while it does provide base and entry level information we are not able to view exactly what information they were able to see at the time of the event. For example, when an agent accesses a ticket the graphql give the variable of the ticket Id, but i do not know what customer if any is the requester to that ticket. If the behavior is slightly different when they go to a customer profile vs a ticket that would be a great thing to have documentation around we we can get a better idea of exactly is being accessed without needing to blindly open tickets based on the id alone. If we are able to see the results directly within the access log itself, or at the very least the ID of each object that is returned from the query

    example: we query tickets with an ID: 12345, the assigneeID is 14567, the requester id is 4567889 and the follower ids are [123,456,789], etc

    That will give us dramatically more actionable information increasing the usability of the api dramatically.

     

    I would be happy to jump on a call sometime to better explain our use case and desired outcomes.

    0
  • Caroline Kello
    Zendesk Product Manager

    Hi Chester, thanks so much for this detailed feedback. Let me pass it on to the team first for a quick check but I'll definitely take you up on the offer to chat as well. 

    0
  • Caroline Kello
    Zendesk Product Manager

    As a initial reaction we're hesitant to add this information for two reasons: a) the query result could be massive and we've not investigated the feasibility of adding this type of load, and b) this would add PII to our internal logs that we've also not investigated the impact of. 

    I'll keep the discussion going with the team but there's a bunch of investigation and due diligence that would be needed for us to understand if this is feasible. 

    0
  • Shigeichi Nakano

    Hi, We seems to have some cases that logs cannot be found while the target APIs would be called internally. For example, when I opened an end user or an organization from agent workspace, I assume that an API (e.g. /api/v2/users/<id> or /api/v2/organizations/<id>) should be called, but nothing can be found in access log. Regarding to tickets and help center articles, we can find which data has been accessed by analyzing GraphQL log.
    Is this a current limitation of functionality, or do I miss something?

    1
  • Caroline Kello
    Zendesk Product Manager

    HI Shigeichi, apologies for the delayed response! We currently have a dependency on one of our internal services to supply accountID and userID headers; this is why the information isn't showing up for you. Current timeline for getting this resolved is end of August so I'll be back with an update for you then. 

    0
  • Caroline Kello
    Zendesk Product Manager

    Updated the documentation to outline the supported filters; by user, by object and by timestamp.

    0

Bitte melden Sie sich an, um einen Kommentar zu hinterlassen.

Powered by Zendesk