What's New in AskiaField 5.4.9?
If you're skipping a few versions, please don't forget to read the various what's new pages:
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.
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.
- 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:
- 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.