BIM Workflow · Navisworks · XML Export
Navisworks Search Sets:
Create, Export & Share
as .xml
Build dynamic Search Sets, export them as portable .xml files, and import them into any project — the right way to standardize coordination filters across your team.
Creating a Search Set inside Navisworks is just the first step. The real power comes when you can export that set as an .xml file, share it with your team, and import it into any project — so everyone runs the same filters on the same model, every time.
PART 01 Why Export Search Sets as XML?
Navisworks saves Selection Sets and Search Sets inside the .nwd or .nwf file. That works fine for single-project use — but it creates a problem at the team level.
If each coordinator builds their own sets from scratch, you end up with inconsistent filter conditions across the team. One person's "Level 3 MEP" might catch different elements than another person's "Level 3 MEP" depending on how they set up the conditions. Clash test results become incomparable.
💡 The XML advantage: Exporting Search Sets as .xml gives you a plain-text, version-controllable, shareable file that contains the exact filter conditions. Drop it in a shared drive or Git repo. Everyone imports the same file. Everyone runs the same filters. Coordination results are consistent and comparable.
One coordinator builds and validates the sets. The rest of the team imports the XML — no re-building, no inconsistency.
Maintain a master XML per project type (residential, commercial, industrial). Start every new project from the right template.
XML is plain text — commit it to Git, track changes, roll back if conditions need to change. Treat it like code.
Anyone can open the XML and see exactly what conditions are being applied. No black boxes, no guesswork.
PART 02 Creating a Search Set — Step by Step
Before you can export, you need a Search Set. Here's the full workflow from scratch.
Go to Home tab → Select & Search → Find Items. The Find Items dialog opens — this is where you define the filter logic for your Search Set.
Home → Select & Search → Find ItemsAt the top, set Search In to the appropriate scope — All for whole-model, or select a specific appended file to scope to one discipline. This scope setting is also saved in the XML.
Click + to add condition rows. Each row has: Category (e.g. Item, Element) → Property (e.g. Category, Level) → Condition operator → Value. Chain multiple conditions with AND / OR logic.
Click Find All. Inspect the highlighted elements in the viewport. Verify the result matches your intent before saving — this is the condition set that will be exported to XML.
Find Items → Find AllClick Save Search. The set appears in your Sets window with a magnifying glass icon. Rename it immediately using your team's naming convention — e.g. MEP - HVAC - All Levels.
Condition Operators Reference
| Operator | Matches when… | Best used for |
|---|---|---|
= |
Value is exactly equal | Known exact category names, specific floor levels |
!= |
Value does not equal | Excluding a specific discipline or type |
contains |
Value string contains the search term | Material names, type names with suffixes/variants |
does not contain |
Value string does not contain the term | Filtering out a sub-group within a category |
starts with |
Value begins with the search term | Prefixed element IDs, structured type names |
is defined |
Property exists on the element | Finding elements that have a specific parameter |
is not defined |
Property does not exist on the element | QA checks — finding elements missing required data |
💡 Always prefer contains over = for material and type conditions. Model authors frequently append version numbers, regional codes, or suffixes to type names. contains "Concrete" catches every variant. = "Concrete" catches only exact matches.
PART 03 Exporting Search Sets as .xml
Once your Search Sets are built and verified, exporting them takes about 10 seconds.
If not already open: Home → Select & Search → Sets. Your saved Search Sets and folders are listed here.
Home → Select & Search → SetsClick a single Search Set to export just that set. Or click a folder to export all sets inside it. You can Ctrl+click to select multiple individual sets across folders.
Right-click the selected item(s) → Export. A Save dialog appears. Choose your destination folder and give the file a clear name — e.g. SearchSets_MEP_v1.xml.
Open the exported .xml in any text editor (Notepad, VS Code). You should see your set names, conditions, and operators written in plain XML. If it's readable and matches your conditions — you're done.
📁 File naming recommendation: Include the discipline, scope, and version in the filename.
SearchSets_STR_AllLevels_v2.xml
SearchSets_MEP_HVAC_v1.xml
SearchSets_ProjectTemplate_2026.xml
PART 04 Understanding the XML Structure
The exported XML is human-readable. Understanding its structure helps you edit conditions directly in a text editor — faster than clicking through the UI for bulk changes.
name attribute is the display name in NavisworksFull XML Example — MEP Ductwork, All Levels
<?xml version="1.0" encoding="utf-8"?>
<exchange>
<selectionsets>
<!-- Search Set 1: All Ductwork -->
<searchset name="MEP - HVAC - All Ductwork">
<findspec disjoint="0">
<conditions>
<condition test="equals">
<category>Item</category>
<property>Category</property>
<value>Ducts</value>
</condition>
</conditions>
</findspec>
</searchset>
<!-- Search Set 2: Piping over 150mm -->
<searchset name="MEP - PIPE - Over 150mm Diameter">
<findspec disjoint="0">
<conditions>
<!-- Condition 1: must be pipe category -->
<condition test="equals">
<category>Item</category>
<property>Category</property>
<value>Pipes</value>
</condition>
<!-- Condition 2: diameter >= 150mm -->
<condition test="greater_or_equal">
<category>Mechanical</category>
<property>Diameter</property>
<value>150</value>
</condition>
</conditions>
</findspec>
</searchset>
<!-- Search Set 3: Level 3 Structure -->
<searchset name="STR - Level 3 - All Structural">
<findspec disjoint="0">
<conditions>
<condition test="contains">
<category>Item</category>
<property>Category</property>
<value>Structural</value>
</condition>
<condition test="equals">
<category>Element</category>
<property>Level</property>
<value>Level 3</value>
</condition>
</conditions>
</findspec>
</searchset>
</selectionsets>
</exchange>
📝 Key attribute — disjoint="0": This controls the AND/OR logic between conditions. disjoint="0" means AND (all conditions must match). disjoint="1" means OR (any condition can match). You can edit this directly in the XML without reopening Navisworks.
PART 05 Importing XML into Navisworks
Importing is even simpler than exporting. Any team member can load your XML file and instantly have the same Search Sets — with the exact same conditions — without building anything from scratch.
Home → Select & Search → Sets. Make sure you can see the Sets panel.
Right-click any empty area in the Sets window, or right-click an existing folder if you want the imported sets to land inside it. Select Import from the context menu.
Sets window → right-click → ImportNavigate to the shared .xml file and open it. The Search Sets from the XML appear immediately in your Sets window — ready to use.
Double-click one of the imported Search Sets. Elements should be selected in the viewport. If the results look correct, the import was successful. If nothing is selected, the model's property naming may differ — check the condition values against actual element properties.
⚠️ Property name sensitivity: Search Set conditions match against the exact property names and values in the model. If your XML says Category = "Ducts" but the model has Category = "Duct" (no "s"), the set returns zero results. Always verify against the actual Properties panel for one representative element before finalizing your XML conditions.
PART 06 Editing XML Directly — Faster Than the UI
Once you understand the XML structure, it's often faster to edit conditions directly in a text editor than to click through the Find Items dialog — especially when you need to duplicate a set across multiple levels or disciplines.
Example: Duplicate a Set Across All Levels
<!-- Copy-paste this block and change only the name + value -->
<searchset name="STR - Level 1 - All Structural">
<findspec disjoint="0">
<conditions>
<condition test="contains">
<category>Item</category>
<property>Category</property>
<value>Structural</value>
</condition>
<condition test="equals">
<category>Element</category>
<property>Level</property>
<value>Level 1</value> <!-- change to Level 2, Level 3... -->
</condition>
</conditions>
</findspec>
</searchset>
<!-- Paste again for Level 2, Level 3, Level 4... -->
<!-- Only 2 things change per copy: name attribute + Level value -->
Building 10 level-based Search Sets in the UI takes 10 minutes of clicking. Copying and editing that XML block 10 times in VS Code takes about 2 minutes. For large projects with many floors, XML editing is dramatically more efficient.
Build once in the UI to get the XML structure right.
Scale in the text editor.
PART 07 Team Workflow — Recommended Setup
Here's the workflow I use on multi-discipline projects to keep Search Sets consistent across the team:
One person (BIM lead or coordination manager) builds and validates all Search Sets in Navisworks, then exports the full set library as a single XML file.
Place the XML in a shared drive or project folder. Name it with version: SearchSets_ProjectName_v1.xml. This is the team's source of truth for filter conditions.
Each team member imports the XML into their Navisworks session at the start of the project. Everyone runs the same filters from the same conditions.
When conditions need to change (new floor added, scope change), the BIM lead updates the XML and increments the version. Team members re-import. Changes are visible as a text diff — exactly what changed, and when.
💡 Git tip: If your team uses Git for any project files, add the Search Set XML to the repo. git diff on an XML file shows exactly which conditions changed between versions — far more useful than "I updated the sets" in a meeting chat.
🎯 Key Takeaways
Search Sets are dynamic filters — they run against the current model state every time. Exporting them as .xml makes them portable, shareable, and version-controllable — treating your coordination filters like the project asset they actually are.
Build your master XML once. Scale it in a text editor for multi-level or multi-discipline variants. Store it centrally. Import it everywhere. When the model changes, update the XML and re-import — consistency maintained with minimal overhead.
In the next post, I'll cover Clash Detective test configuration — how to wire your Search Sets directly into clash tests and export results that are actually actionable for the design team.
