Fields such as WaterfrontFeatures, ParkingFeatures and PoolFeatures hold a list of values, not one value. Filtering on a single entry inside that list has to be done at the import step, using Custom parameters on the import task, because once the listing is on your site the list is stored as one piece of text.
This page covers how to write that filter and what it can and cannot do.
Why the display side cannot do it precisely
When the MLS returns a list, MLSImport joins it into a single value separated by commas. A listing with lakefront and navigable water is stored as Lake Front, Navigable Water in one field.
Any theme filter over that field is therefore a text match over the whole string. It cannot reliably distinguish a listing that is lakefront from one that merely mentions a lake in another entry, which is why granular waterfront and parking filters built on the display side give wrong counts.
Some list fields are an exception. InteriorFeatures, ExteriorFeatures and Appliances are routed to the features taxonomy, where each entry becomes its own term and can be filtered exactly.
Filtering at the import step
Every import task has a Custom parameters field under Import Parameters. What you type there is a filter expression in your MLS’s own query language, forwarded to the RESO API with your other filters.
- Open the import task and scroll to Custom parameters.
- Enter the expression alone, with no
$filter=in front of it. For exampleWaterfrontYN eq true. - For a value inside a list, use a contains expression:
contains(WaterfrontFeatures,'Lake Front'). - Combine conditions with
andandor, and group them with parentheses:WaterfrontYN eq true and (contains(WaterfrontFeatures,'Lake Front') or contains(WaterfrontFeatures,'Navigable Water')). - Update the task, then read the listings found count. It should drop to the narrower set.
Your custom expression is joined to the filters you picked in the dropdowns with and, so a postal code selected above and a custom expression here both apply.
The on screen example in the field shows a $filter= prefix. Leave it out. An expression containing $filter, a question mark, an ampersand or a semicolon is rejected before the request is sent, and the run stops with that reason instead of importing.
Rules the expression has to follow
- Parentheses must balance. A single stray one at the very start or end is removed for you, anything else is rejected.
- String values are wrapped in single quotes, exactly as the MLS publishes them.
'Lake Front'and'Lakefront'are different values. - Field names are the RESO names on your feed, spelled as they appear in Select Import fields.
- Whether a function such as
containsis supported is decided by your MLS’s server, not by MLSImport. A server that does not support it answers with an error, which the run reports.
Splitting the work across tasks
One expression per task is the practical unit. When you want lakefront listings in one place and horse property in another, create two import tasks with the same area filters and a different custom expression in each.
This also keeps you under the limit on total filter length. Selecting a long list of cities plus a long expression can exceed what the query allows, and the task tells you to split rather than sending a request that fails.
Test the expression with a small import first. Set How Many to import to five, run it, and check the five properties actually carry the value you filtered for. That catches a spelling difference in the MLS value in a minute rather than after a full import.
Frequently asked questions
Where do I find the exact values my MLS uses in a list field?
Import a handful of listings you know qualify and read the field on one of them in wp-admin. The stored text is the feed’s own wording, which is what your expression has to match.
Can I filter on a field I did not select for import?
Yes. The filter runs at the MLS, so it works on any field your feed exposes. Selecting the field for import only decides whether the value is stored on your properties afterwards.
My expression is accepted but returns zero listings. What is wrong?
Usually the value, not the syntax. Check capitalisation and spacing inside the quotes, and confirm the field is actually populated on your feed rather than merely defined.
Can the same listing come in through two tasks with different expressions?
Yes, and it is worth avoiding. A listing matching two tasks is imported once and then claimed by whichever task ran last, which makes counts and agent assignment unpredictable.
Related
- Controlling which listings are imported
- Avoiding overlapping import tasks
- Understanding RESO fields
- Search fields not populating as expected
Send us the field and the values you want, and we will write the expression for your MLS.