Remote Logging Configuration and Administration

In 2022 we started adopting third-party product LogRocket to help us troubleshoot incidents happening at our clients. The product allows detailed monitoring and troubleshooting of Zendesk sessions by submitting browser events and logs to the server where our technical team has access to view and analyse them.

This capability is vital in circumstances where issues reported are not easily reproduced either in our development environment, or your prod and non-prod environments.

In the past we issued a LogRocket-enabled service patch to clients that were reporting such issues, and assigning to each client their own LogRocket project. This worked well, but had its own issues - clients were not automatically updated when a new release or patch of the connector app was released on the Zendesk marketplace and we had to update the LogRocket-enabled patch separately which was error prone. Patch also lacked any redaction of client’s PII data.

With release 2.4 of the connector app we made remote logging via LogRocket an integrated part of the app, available to all clients. This will facilitate troubleshooting of hard to reproduce, client-specific issues out of the box. Note that as a connector app user you don’t need to install or configure LogRocket yourself.

Logs collected this way are augmented with metadata that enables our technical team to filter entries by your agent’s usernames, or their routing profile and your Zendesk domain (via routingProfile and zendeskClient LogRocket user traits).

Starting from release 2.6 the remote logging needs to be activated using a special short term code supplied by us on your request.

Use Case Scenarios

Note: both scenarios below assume we were unable to reproduce the issue in our own development environment. We will do our best to reproduce the issue internally first, before resorting to remote logging.

1. You are able to reproduce the behaviour in your non-production environment. In this case you should enter the provided remote logging code in the Remote logging field, and tick the Unredacted logging checkbox in app settings. This will give us the best data and insight into the issue at hand.

2. You are unable to reproduce the issue in your non-prod environment. The behaviour is present in your production environment only. In this case you should only enter the remote logging code in the
   Remote logging checkbox and leave the Unredacted logging checkbox cleared. This will ensure your PII data is redacted.

After troubleshooting is completed and issue is successfully diagnosed, both settings should be reverted back to their cleared state. The short term code expires after the agreed number of days and remote logging will automatically stop at that time.

Any logs collected will be automatically erased from LogRocket servers after 30 days, or can be manually erased sooner on your request.

What Data is Redacted

When redaction is turned on (default) the following will happen:

• Since the connector app is hosted in an iFrame within Zendesk UI, only the UI of the app is visible within LogRocket events videos, the rest is masked. Amazon Connect CCP is also masked. LogRocket also automatically hides any UI elements labelled as private - in our case this is customer name in manual ticket assignment mode.

• Network logs (API requests and responses) are disabled.

• Data in console logs are redacted as follows (see also detailed technical spec at the end of this page):

  • all string type values are tested with regular expression patterns (valuePatterns). Any matches are replaced with [redacted] string. This works for both, plain strings values in log statements and string values as properties of objects. Value patterns look for most common PII data such as phone numbers, emails and customer full names;

  • certain data that might not always match a pattern, but we know should be redacted, are labelled as PII programmatically, so they’re always redacted;

  • object keys (property names) are tested against their own set of regular expressions (keyPatterns). If a match is found then the entire corresponding property value is replaced with [redacted]. Default key patterns look for phone numbers, email and street addresses, person names, user IDs and passwords. We have ensured all standard Zendesk user and ticket fields are catered for;

  • custom contact flow attributes are a special type of object and follow this rule: the value of the name property is tested against keyPatterns. If matched, then its corresponding value property is replaced with [redacted];

• Console logs at debug level are disabled. These log entries may be used in unredacted mode to further help troubleshooting, however they proved to be tricky to redact using patterns so it’s best to omit them altogether.

Extended Redaction Configuration

The following are the default key and value patterns for testing PII data:

let keyPatterns = [
  "^(?=.*(?:phone|mobile))(?!.*(?:business|company)).*$", // phone numbers, except business or company
  "^(?=.*(?:email|address|street))(?!.*(?:company)).*$", // email and street addresses except company
  "^(?=.*(?:name|first|last))(?!.*(?:company|business|brand|field|product|app)).*$", // name except listed exceptions
  "(?:user|login)[_-]?id", // user or login id
  "pass[_-]?word", // password
  "secret", // various secrets
];

let valuePatterns = [
  "\\[pii:([^\\]]+)\\]", // internally labelled PII data
  "\\b[A-Z][a-z]+(?:\\s[A-Z][a-z]*\\.*)?\\s[A-Z]{1}[a-z]+\\b", // full name
  "\\b[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\\.[A-Za-z]{2,}\\b", // email address
  "\\+\\d{1,3}(?:[\\s-]?\\d){9,11}", // international phone number
  "(?:0\\d{1,4}|\\((?:\\d{3}|0\\d{1,4})\\)|\\d{3})(?:[\\s-]?\\d){6,13}" // local phone number
];

You may however extend both types of patterns by providing a URL to a JSON formatted configuration file, like the one below. This will then cater for any custom user and ticket fields that you may use.

{
  "keyPatterns": [
    "^(?=.*(?:birth|DOB)).*$",
    "^(?=.*(?:licen[cs]e)).*$",
    "^(?=.*(?:social[_-]?sec|ssn)).*$",
    "^(?=.*(?:passport)).*$",
    "^(?=.*(?:account)).*$",
    "^(?=[\\w-]*expir)(?=[\\w-]*date)[\\w-]+$"
  ],
  "valuePatterns": [
    "\\d{3}[-.]?\\d{2}[-.]?\\d{4}",
    "\\d{1,5}[A-Za-z]?\\s[A-Z][a-z]+\\s[A-Z][a-z]+\\b",
    "\\b4\\d{3}(?:[\\s-]?\\d{4}){3}\\b",
    "\\b5[1-5]\\d{2}(?:[\\s-]?\\d{4}){3}\\b",
    "3[47][0-9]{2}(?:[-\\s]?[0-9]{6})(?:[-\\s]?[0-9]{5})?"
  ],
  "valuePatternComments": [
    "US social security number (SSN) or US passport number",
    "Street address",
    "Visa card number",
    "Mastercard card number",
    "American Express card number"
  ]
}

Note: the last node "valuePatternComments" is not used and is there just for documentation of corresponding value patterns. Key patterns are usually self-explanatory.

The URL configured to access the file must be CORS enabled and allows access from any domain.