Fields & Links

tl;dr to reference a field write e g description description if a field contains spaces or other special characters, write e g \[billing city] \[billing city] to reference a field of a related module, write e g calls calls subject subject use \<all!> \<all!> before a link name to specify "all and at least one" records for example, typing \<all!> \<all!> calls calls \[ start date start date ] = tomorrow tomorrow in accounts will find all accounts that have at least one related call, and all their related calls start tomorrow use \<all?> \<all?> to specify "all or none" for example, typing \<all?> \<all?> calls calls \[ start date start date ] = tomorrow tomorrow in accounts will find all accounts that either have no related calls, or if they do, they all start tomorrow discover fields & links docid\ kzbtllyb4xfj8df290vxi use \<some> \<some> to specify "one or more" for example, typing \<some> \<some> calls calls \[ start date start date ] = tomorrow tomorrow in accounts will find all accounts that have one or more related calls that start tomorrow the \<some> \<some> can be omited, so typing calls calls \[ start date start date ] = tomorrow tomorrow gives the same result field names a field is referenced by its name if the name contains spaces or other special characters, enclose it in square brackets \[ ] if for some strange reason, the character ] is part of the actual name of the field, precede it with a backslash \ both system names and labels can be used when auto filling from a visual elements docid\ p4uiqlb6kdnaoydfb8uhb , quickquery uses the label variant if it's available, and automatically adds brackets and backslashes if they're needed fields in linked records to reference a field in a related module, write the name of the link, followed by a period , and then the name of the field link names follow the same rules as stated above (square brackets when special characters are involved etc ) quantifiers the query above searched for accounts accounts that have some some (i e at least one) opportunity opportunity having likely likely > > $25k $25k however, you could easily want to search for accounts where all opportunities have likely likely > > $25k $25k this is what quantifiers are for quantifiers are written before the link name , and enclosed in < and > there are three quantifiers in quickquery \<some> \<some> at least one linked record satisfies the condition \<all?> \<all?> all linked records satisfy the conditions or no linked records exist \<all!> \<all!> all linked records satisfy the condition, and at least one linked record exists if you omit the quantifier, it is interpreted as \<some> \<some> difference between all! all! and all? all? the only difference between \<all!> \<all!> and \<all?> \<all?> is how they treat situations where there are no linked records \<all!> \<all!> excludes those records, while \<all?> \<all?> includes them think of the question mark ❓ as a " maybe exists? ", while the exclamation mark ❗as a " must exist! " to understand why this is useful, imagine you want to find out which accounts haven't been called in the past month in other words, all all calls calls are strictly before strictly before last month last month \<all!/all?> \<all!/all?> calls calls \[ start date start date ] strictly before strictly before last month last month the question is, what quantifier should you use \<all?> \<all?> or \<all!> \<all!> ? well, let's think about it what if an account had no calls at all, ever ? that would certainly qualify as the type of account you would want to see on your list, wouldn't it? and that's precisely why \<all?> \<all?> is there for you to use contrast that with the query on the picture above, which looks for accounts accounts where all opportunities opportunities are expected to close the month after next, or later in that situation, it is obvious that you don't want to see accounts that have no opportunities it makes no sense and that's why you would use \<all!> \<all!> the only thing you need to remember is this when searching by related fields, always think about how you want to treat situations where no linked records exist do you want to include them? use \<all?> \<all?> do you want to exclude them? use \<all!> \<all!> negating quantifiers let's take a look at the following two queries (we're in accounts) tasks tasks description description not empty not empty not not ( ( tasks tasks description description empty empty ) ) obviously, both are somehow asking for accounts accounts where the task task description description isn't empty empty however, there is a difference between the two the first query is easy to understand we didn't include a quantifier, so it's \<some> \<some> , which means that we're looking at accounts accounts where at least one task task doesn't have an empty empty description description the second query is a little trickier the inside part denotes accounts accounts where at least one task task does have an empty empty description description this is wrapped in not ( ) not ( ) , which means it's the opposite however, the "oppositeness" doesn't only apply to the empty empty part, it also applies to the \<some> \<some> part! to figure out what the opposite of \<some> \<some> is, it is useful to translate it to its technical meaning, which is "exists" in other words, the inside query is "a task task with an empty empty description description exists exists " the opposite of that is "a task with an empty empty description description doesn't exist doesn't exist " and if such a task doesn't exist, it means that either all linked tasks tasks have non empty descriptions descriptions , or no linked tasks tasks exist at all whew! 🥵 math class ptsd flashbacks anyone? yeah, us too that's why we prepared the table bellow, where you can simply look up the negation of a given quantifier if you ever need it, and be done with it you can find some examples bellow as well quantifier technical meaning negation negated quantifier \<some> \<some> x at least one linked record exists that satisfies x either all linked records satisfy not not x or no linked records exist \<all?> \<all?> not(x) \<all?> \<all?> x every linked record satisfies x or no linked records exist at least one linked record satisfies not not x \<some> \<some> not(x) \<all!> \<all!> x every linked record satisfies x either at least one linked record satisfies not not x or no linked records exist \<some> \<some> not(x) or "empty" (see example) bellow) example for \<some> \<some> the following two queries are equivalent example for \<all?> \<all?> the following two queries are equivalent example for \<all!> \<all!> the following two queries are equivalent quantifier ordering when using quantifiers, their order begins to matter take the following two queries for instance (we're in accounts) at first glance, we might feel that both should give the same result, but this is not the case the reason for this can be seen when you read those queries out loud the query on the left is saying "accounts where every opportunity id equals some opportunity id under that account" well, when you think about it, that's always the case! naturally, every opportunity id is equal to itself, so there will always be at least one opportunity id under that account which will match! however, the query on the right is saying "accounts where some opportunity id equals every opportunity id", which is a very different beast it means that one id must be the same as all the other ones , which basically means that they must all be the same! since ids are always unique, this can only occur when there is a single record, since that is the only situation where " one equals all "