Searching tips: combined queries

This article is an in-depth look at searching using multiple terms; make sure you’ve brushed up on your single query search knowledge beforehand. If you are just getting started, start here first.

Operators ("AND", "OR", "NOT")

When searching for leads that match multiple conditions, we can simply specify them one after another, in any order:

*city:"New York" calls > 0 calls > 0 city:"New York"

These two queries are equivalent and will find leads with at least one call and where the city field matches New York.

For more advanced queries, use the operators and, or, and not.

The and operator matches if all conditions are true. This operator is always implied (and therefore optional). We can make the search shown above more readable by making the implied and more explicit:

city:"New York" and calls > 0

The or operator matches if at least one of the conditions is true:

city:"New York" or city:"San Francisco"

This finds leads that are either in New York or in San Francisco.

The not operator negates the query that follows immediately after it:

not city:"San Francisco" and state:CA

state:CA and not city:"San Francisco”

Both queries match leads where the state is California, but the city is not San Francisco.

Another way to say "OR"

A lot of "ors" in a search can make searches slower. For example:

state:ME or state:NH or state:MA or state:RI or state:CT or state:NY or state:NJ or state:DE or state:MD or state:VA or state:NC or state:SC or state:GA or state:FL

If you want to find leads that match a variety of different values for a single field, you can ditch the or and format them like this:

state in (ME, NH, MA, RI, CT, NY, NJ, DE, MD, VA, NC, SC, GA, FL)

Now your search will process faster (and it's easier to read too).

Grouping using parentheses

When using different operators, parentheses can be used to group the query:

not city:"San Francisco" and not city:"New York"

not (city:"San Francisco" or city:"New York")

These two queries are equivalent and show all leads that are not from San Francisco and not from New York.

When mixing and and or operators, parentheses should always be used to clarify the meaning of the query:

contact_name:john and (city:"San Francisco" or city:"New York")

(contact_name:john and city:"San Francisco") or city:"New York"

The first search will match leads with a contact named John and are in San Francisco or New York. The second search will match leads from San Francisco with a contact named John - and any lead from New York, regardless of the contact's name.

Nested object grouping

You can create searches that match objects that are nested in the lead (emails, calls, opportunities, contacts, etc). Let's say we want to find leads with won opportunities that are worth more than $100:

opportunity_status:won and opportunity_value > $100

This seems like it should work. However, this query is actually looking for leads with any won opportunity and any opportunity where the value is greater than $100. To say it in plain English, we're asking Close to "show any opportunities that are in a 'won' status, and also show any opportunity (regardless of the status) with a value greater than $100."

So in addition to pulling in leads with won opportunities that are worth more than $100 like you'd expect, you’ll get some other results, too: A lead with a $200 lost opportunity and a $50 won opportunity would match this query as well.

To create more targeted searches, you’ll need to use nested grouping. Nested grouping allows you to limit multiple search conditions to a specific nested object.

Put another way, nested grouping allows you to combine multiple search questions (“Does the lead have a won opportunity? Does the lead have an opportunity worth more than $100?”) into one more specific question (“Does the lead have a won opportunity that’s worth more than $100?”).

Building a nested object search

Provide the name of the object type (contact, task, opportunity, call, note, email, etc.) followed by parentheses:

opportunity( )

Inside the parentheses put the object-specific query:

opportunity(opportunity_status:won and opportunity_value > $100)

You can remove the object type prefix (opportunity) inside the parentheses to make the query more compact and readable:

opportunity( status:won and value > $100 )

Now we get what we originally wanted: Leads where both conditions match on a specific opportunity.


We want to see all leads that have calls made by John which were longer than 30 seconds and contained the text “happy” in the call note:

call( note:happy by:John duration > 30s )

Since happy is in the parentheses following call, happy will only be searched for in calling-related activities within Close. Leads that only have happy appear in other object types (like a note or an email) won’t match. Since happy won't trigger a match outside of a call activity, we can just use full-text search inside the query:

call( happy by:John duration > 30s )

Let's try another one. This query matches leads who have replied to our template "Initial Outreach" sent by John during the first week of April:

email(direction:sent template:"Initial Outreach" user:John sent >= 2014-04-01 sent <= 2015-04-07 has_reply:yes)

Multiple field sorting

We can sort by multiple fields separated by commas:


This will show leads with the lowest priority value first and then search within each priority group by descending number of activities (most activities first).

Smart view queries

Frequently used search queries can be saved as smart views. Sometimes it's useful to create a search or a new smart view based on an existing smart view. Instead of repeating the query belonging to an existing smart view, you can use the in keyword:

in:"Interesting Leads" and state:CA

This will match all leads that are currently in the Interesting Leads smart view and are located in California.

Limiting number of results

If you have a search query that you want to limit to fewer results, use the limit: keyword. This is useful if you only want to bulk edit or bulk email some of the matching leads.

limit: 100 would show only 100 results, regardless of the total number of matches.

So as a real-world example, let's say you have more than 15,000 leads currently in a trial status that you haven't called yet today. That's a daunting number. So instead, to track your progress through the day, you could use this search:

lead_status:Trial calls < 3 not call_date:today sort:-created limit:100

This would limit it only 100 trial status leads you've called less than 3 times total, haven't called yet that day, sorted from newest to oldest. The list would slowly reduce in number as you call each of the 100 leads. On the following day, you'd receive a new 100 Leads to call.

Splitting up / distributing results

The slice keyword splits a list of leads into separate chunks. It’s a great keyword to use when you want to make sure different people aren't working on the same leads Dividing up existing Smart Views with slice is a great way to assign leads without any manual work.

Let’s start off with a Smart View called "Hot Leads" and a group of 3 people who want to work with those leads. Slice can help us separate the "Hot Leads" results into 3 groups (without overlapping). Jane, person 1 of 3, can use this query to get approximately one-third of the results from the "Hot Leads" Smart View:

Jane, the first person, uses: slice:1/3 in:"Hot Leads"

Joe, the second person, uses: slice:2/3 in:"Hot Leads”

Sarah, the third person, takes a different approach and only wants to concentrate on the Hot Leads that have been called by Joe at any point in the past:

slice:3/3 call_user:Joe

Even though Sarah's search above has extra criteria about Joe's calls, by adding in slice:3/3, you are guaranteeing that none of Sarah's results will show up in Jane or Joe's searches - and vice versa.

Note that the number of leads in each "slice" may not be exactly equal. Slice is more concerned about making sure the same lead never appears in different slices (even when there are additional queries added in after the slice keyword).

Lead/opportunity status range search

We can perform historical searches on lead and opportunity statuses using keywords lead_status, opportunity_status (and some parentheses, of course). The inner query (the bit inside parentheses) accepts the keywords status, from, to, after and before.

This will match leads that were in status Trial any time in January:

lead_status(status:Trial from:"January 1st" before:"February 1st"

Let’s get more specific. Here are leads that were in status Trial on January 1st and ended up being in status Customer on February 1st:

lead_status(status:Trial on:"January 1st") and lead_status(status:Customer on:"February 1st")

Opportunity statuses are also supported and can also be contained in a nested (parenthetical) query. Use this to match leads with opportunities in status Active on January 1st and moved to status Won by February 1st:

opportunity_status(status:Active on:"January 1st") and opportunity_status(status:Won on:"February 1st") )

Time zone and local time searches

While the timezone keyword searches for leads that have a phone number/address that matches a specific timezone, the timezone keyword can show leads that are in a specific time window:

timezone > 9am timezone < 5pm

You can also add in a sort keyword to order your matching leads from east to west:


Timezones can be tricky. A few things to remember:

  • A lead can be associated with multiple time zones if it has multiple addresses or phone numbers with different area codes.
  • If you know that either phone numbers or addresses will be a better timezone predictor, add phone_ or address_ to your timezonekeyword (e.g. phone_timezone , address_timezone).
  • When you search for a particular local time, we find leads where any of their time zones match the time zone / local time you requested.
  • Keep in mind that the "Local time" column is not capable of showing multiple local times. If multiple time zones are associated with a lead, one local time is displayed at random.

Updated 11 months ago

Searching tips: combined queries

Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.