Configuring Property Mapping

This article walks you through setting up Property Mapping for the model files in your Navisworks document. If you are new to Property Mapping, read the Introduction to Property Mapping article first — it explains what the six mapped fields are and why they matter.

Before you begin

You will need:

A saved Navisworks document. Save your file before configuring.
At least one clash test with results. Run your clash tests in Navisworks Clash Detective first — ClashWise reads the models involved in your clash results.
To be signed in to the ClashWise plugin. Property Mapping is included with every plan, including the trial.

Where to find it

In Navisworks, open the ClashWiseAI ribbon tab.
In the General panel, click Property Mapping.

The window opens alongside Navisworks (it is not always-on-top, so you can keep working in the model while it is open). It also opens automatically — at the first unmapped model — if you click Start in the Title Update window while mappings are incomplete.

The model tree

The left side of the window lists every source model in your document as a tree:

Sources are the authoring files your models came from (for example each .rvt or .dwg). Configure a source once and everything under it inherits that mapping.
Levels appear as children under a source when it is split across several appended files (a common export style: one file per level from the same model). Levels inherit the source's mapping — you only touch a level if some of its fields need different properties.

Two markers keep you oriented:

A warning icon on a source or level means its mapping is incomplete.
A dot (●) on a level means it carries its own field overrides instead of inheriting everything.

A blue header above the editor always states exactly what you are configuring — the source, or a level within it.

Step 1 — Select a source and review the six fields

Click a source in the tree. Auto-detection runs for unmapped models when the window opens — including pre-selecting the source-file property (for example Item → Source File) for the Source Property — so most fields are usually filled in already. Review each of the six required rows (all marked with a red asterisk):

Name Property — the element's descriptive name.
ID Property — the element's unique identifier from the source application.
Category Property — the element's classification (for example "Walls" or "Pipes"). Whatever property you choose here is also what your clash matrix classes are matched against.
Layer/Level Property — the floor level or CAD layer.
Type Property — the specific type within a category.
Source Property — the source authoring file the element came from.

Each field is a pair of dropdowns: first pick the property category to look in, then the property within it (the second dropdown activates once a category is chosen). Both dropdowns are editable — you can type an exact name if you know it. Hover the info icon next to any field name for a detailed description of the value it should produce.

Step 2 — Fix anything auto-detect missed

Auto-detection works well for models with standard property names, but you may need to adjust fields when a model uses non-standard or translated property names. Some pointers:

Revit models commonly keep element data under an "Element" category (Name, Element ID, Category, Level, Type).
AutoCAD-based models often use "Item" or "LcOaNode" categories, with a "Layer" property instead of a level.
IFC exports often use "Item" or IFC-specific categories, with properties like "IfcClass" for the classification.
Source is usually held by an Item → Source File style property, which auto-detect finds on its own. If a model has none, map the field to whatever property most reliably identifies where elements came from.

Property names may appear in another language if the model was authored under a different locale — that's fine. Select them exactly as they appear.

Step 3 — Verify with Preview or Sample Elements

Two ways to confirm your mapping reads real data correctly:

Sample Elements — the quickest check. ClashWise samples representative elements from the selected source (or level) under a progress bar and fills the preview grid with their mapped values. No clicking in the model needed; you can cancel a long sample at any time.
Preview — a live check driven by your own selection. Click Preview, then click elements in the Navisworks model view; the grid fills in as you select. Clicking a row in the grid selects that element in Navisworks, so you can cross-check the values against the native Properties panel.

In both cases, check that each column shows the kind of data you expect — names in the Name column, identifiers in the ID column, and so on. A few blank cells are normal (not every element carries every property), but a column that is consistently wrong or empty means that field is mapped to the wrong property. Adjust the field and sample again.

Two more buttons sit alongside the grid tools:

Isolate (eye icon) — isolates the selected source or level in the Navisworks view so you can see exactly which geometry you are mapping. Isolating another model replaces the previous isolation; clicking again on the same one restores full visibility.
Clear (bin icon) — clears the selected source's mapping, or a selected level's overrides so it inherits the source again. You are asked to confirm.

Step 4 — Override a level only where it differs

Levels inherit their source's mapping, so most of the time there is nothing to do per level. When one level's data genuinely lives elsewhere:

Select the level in the tree. The editor shows its effective (inherited) mapping.
Change just the fields that differ. Each change is saved as an override for that level only — the level gets a dot (●) in the tree, and overridden fields show a small reset arrow.
Click a field's reset arrow to drop that override and inherit the source again.

To copy one level's overrides to its sibling levels, use Apply to Other Models... while the level is selected — the dialog lists the other levels of the same source. Applying from a level that has no overrides of its own resets the chosen siblings to inherit too.

Step 5 — Apply the configuration to similar models

If several source models share the same structure (for example, several Revit models from the same project), you don't need to configure each one by hand:

Finish and verify one source's configuration.
With that source selected, click Apply to Other Models....
Tick the models that should receive the configuration (or click Select All), then click Apply.
You will see a confirmation such as "Configuration applied to 3 model file(s)", and the warning icons on the updated models clear immediately.

Only apply a configuration to models from the same source application — a Revit mapping will rarely fit an IFC export. After applying, select each target model and spot-check it with Sample Elements.

What happens next

Everything is already saved. Changes save automatically as you make them — there is no Save button. Mappings are stored per model file on your computer and persist across sessions and documents.
The Title Update run unlocks. The Start button in the Title Update window requires every listed model to have all six fields mapped — if any are missing, it opens this window at the first unmapped model.
Publishing benefits too. The element information sent to the web with each published clash comes from these mappings.

Occasionally, during other data-extraction flows (such as creating a clash matrix from the plugin's Wise chat), ClashWise may ask you to confirm which property identifies element categories in a dialog titled Select Category Property. Choose the same category and source properties you configured here.

Tips

Configure and verify one model of each source type first, then use Apply to Other Models... for the rest.
Sample elements from different disciplines and levels, not just one area of the model.
Reconfigure when new model files are added, when a model is re-exported with a different structure, or after changing the Navisworks display language — mappings remember the language they were made under, and a language change triggers re-detection.
Agree on consistent property standards with your modeling team; the more standard the models, the better auto-detection works.