What's New in AskiaField 5.4.9?

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.







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



  • 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-explanary) 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.





Have more questions? Submit a request