If you're skipping a few versions, please don't forget to read the various what's new pages:

• 5.4.4
• 5.4.6
• 5.4.7
• 5.4.8

We have continued the developments, started with 5.4.8, for the GDPR compliance. With 5.4.9, all your survey and list data can be encrypted on SQL Server side.

Copy-paste quotas across surveys

It is now possible to copy a quota cell entirely in an existing quota definition, and paste is back to a different survey. This is particularly useful for tracker surveys.

Fresh Calls

A new setting has been added to the Task properties > Callback tab: Call % unused contacts:

This setting allows you to always have a certain percentage of fresh contacts among all callbacks.

Here how it works:

• Each time a call is made, the system will verify how many of the last 10 calls were for an unused contact.

• If there are less than the number configured, an unused contact will be used if:
  • There are no contacts where ‘call now’ is enabled.
  • There are no appointments available.
  • There are unused contacts available within quota.

Remarks

• The system will use a ‘sliding window’ of 10 calls to calculate the percentage of unused contacts, and compare this to the configured value. So all calls before the last 10 calls are ignored.
• This setting does NOT overrule quota or skills – it only makes sure unused contacts will be used first if they are available.
• Setting the value to 0 will have no effect.

List Data Encryption

To protect sensitive data from being read in SQL Server directly (either by a DBA or in case of a security breach), sensitive data should be encrypted in database.

On every list field, a user will be able to configure whether a field is encrypted or not:

The data will be encrypted the same way survey data is encrypted. Please refer to this article.

As result, encrypted data will appear like this in SQL table:

Some notes

• A different encryption key will be used per field.
• This encryption key will be stored in the ListsFields table, encrypted the same way as survey data encryption keys (using the master encryption key).
• It will be possible to retrieve the encryption keys using the API.
• If a field is encrypted, using that field in a find contact through the API will be limited: The field will only be allowed in a top-level AND/NOT condition.
  Using the field in a find contact through CCA, Supervisor or CATI will not be impacted (because only top-level conditions are used).
  Also note the performance will be worse for find contact with a condition on an encrypted field.
• Encrypted data will be decrypted when exporting the list to LST.
• If a field is encrypted it won’t be available for quota – so the list will be considered ‘not compatible’ if a quota question has an import for an encrypted list field.
• The external unique ID field cannot be encrypted.

In the general settings, there is  a new setting (quite self-explanatory) to indicate the default encryption for new lists:

By default, the setting is set on "None".

Special considerations for do-not-contact lists:

• We check if a contact’s phone or email address is on a DNC list by comparing the fields on SQL Server.
• If field are encrypted, it is impossible to compare them on SQL Server.

Comparing them on CCA (after decrypting) is not feasible, because we’d have compare potentially millions of records – that would be very slow.

• Solution: use hashes to compare the data:
  • For all fields used in DNC lists (phone, email, derivation) an additional hash will be calculated in a separate field (AskListXXX.<fieldname>_hash).
  • This hash will be the same for identical values.
  • When checking DNC lists, the hashes will be compared.

To handle hash collisions, CCA will check the ‘manually’ by decrypting the data for all matches with an equal hash.