List Practices to Avoid
This article outlines some practices to avoid to improve your experience with .
Self-Referencing Lists
A self-referencing list is a list that directly or indirectly refers back to itself.
To sync list B, it needs to sync List A, but List A depends on List B.
This situation leads to lists that get stuck in very long or infinite loops, causing long processing times and making it hard to track any other issues that may be present in your automations.
Huge Lists
If you use lists with very broad criteria, you may return a very large number of records. The more records your list returns, the longer the processing time may be. Consider what data you actually need before making or maintaining a list.
You may want to find errors or omissions in email address fields. Initially, you'd want to examine all existing records, but after the initial analysis, you don't need to keep checking records you have already checked. You can add list criteria to examine only newly created records so the system doesn't have to keep processing all those historical records.
Excessive NOT Criteria
NOT criteria can be useful. Excessive use of NOT criteria can cause issues for several reasons though. NOT criteria can be inherently more complex to understand when creating lists, leading to mistakes when you're starting out with .
Ruling out all of the things you don't want in a list can also be much more work than simply using IS criteria to search for exactly what you need.
Excessive CONTAINS Criteria
Depending on the size of the data set being searched, it's often better to use IS or IS NOT instead of CONTAINS criteria. Searching for "IS" or "IS NOT" is faster because it directly compares exact values, while "CONTAINS" or "DOES NOT CONTAIN" requires scanning and analyzing the content of each item, which takes more time.
Overuse of One-Time Lists
One-time lists are effective tools for specific, non-recurring tasks, like generating reports, as it's easy to compare a snapshot from one one-time list with another.
One-time lists can't be edited or updated after creation though, so if new records come in or existing ones are updated, this won't show. This makes Always Updated Lists
A collection of ATS records that meets specified criteria, such as a scheduled end date or a low NPS response. more appropriate for most automations.
Building Lists in the Automations Section
Building lists in the Automations section has a number of drawbacks that mean it's better to Create a List via Advanced Search. Building via Advanced Search allows you to test out different list criteria before saving and syncing your list.
Building from the Automations section may require you to go back and forth between the Automation section and the Lists section to check your criteria is working as intended.
Entity Oversights
Be careful when choosing entities for lists. Entities like Submissions and Placements can have multiple records for the same candidate. Any automations you run based off one of these entities could repeat numerous times depending on how many records you have of that type.
You have seven submissions for a single candidate. If you create an automation that updates a candidate's status based on the status of a submission, the candidate's status will potentially update seven times (once for reach submission they have). This may lead to errors.