🧹 Retention Policies and Regular System Cleanup - Devices Edition

Maintaining a clean system is an important part in ensuring the efficiency of your Slate instance. This article outlines some Retention Policies that focus on regular system maintenance regarding the Devices tables. Many of the items defined below require a proficient knowledge of Configurable Joins querying. 

The Why:

The Devices table is a data table that often houses incorrect and unusable data which can impact communication processs while also bogging down the system with bad data. Removing incorrect data can help improve both process and system efficiency. 

Some Useful Devices-Related Retention Policies:

All examples listed utilize the object type of Device and base of Device. These policies can also be configured to run on a regular schedule and do not require regular manual interference. 

Remove devices with invalid values 

This retention policy removes any device with values that include "none", "N/A", "NA", ?", "Not Applicable", or "same".  Additional odd values can be added to tihs policy within the parantheses so long as they are comma separated and within single quotes. 

Remove email addresses with too few characters

This retention policy removes any email address that has fewer than 5 total characters, which would make the address invalid. 

Remove phone values with too few characters

This retention policy removes any phone number that has fewer than 9 total characters. Note: If your institution has a high volume of international records, be advised that there are a few cases wherein a country phone number can be fewer than 9 digits, though they are very rare. 

Remove device values not tied to person or dataset records

A device can become orphaned in the system after the deletion of person or dataset records. Deleting a record in Slate does not delete data in corresponding tables. 

This example requires filters determining the existence of person record GUIDs as well as dataset record GUIDs. The reason for this is telephone and email data for both person and dataset records are housed in the same Devices table. Filtering for only person data could lead you to accidentally delete devices for dataset records or vice versa. 

Remove duplicate person-record email addresses

Note: This example requires use of a indepdendent subquery filters which is a more complex configurable joins concept. This policy will only remove duplicate email addresses from person records; not dataset records. A similar process can be used to remove duplicate phone numbers. 

• • For this retention policy you need to compare the device that will be deleted (main query) to any devlces that are duplications (independent subquery).  This requires comparing the device values but also two additional comparison subquery filters:
    • • One that ensures that you are not looking at the same device in your main query and your independent subquery.
      • The second compares the person-record GUIDs of your main query (device to be deleted) to your idependent subquery (duplicate device that will remain on record). Without this filter, you could accidentally be deleting an email address that belongs on another record. 
      • It is important that your main query is filtering for devices that are NOT rank 1 because the retention policy is going to delete whichever device you are filtering for and you will want to retain the rank1 address. 

Related Links and Articles:

Retention Policy Best Practices (ReWorkflow)

Retention Policy Editor (Knowledge Base)

Retention Policy Object Types (Knowledge Base)

Independent Subqueries (Knowledge Base)