Revit IFC Property Set Mapping: Keep Family Data Intact
Revit IFC Property Set Mapping: Keep Family Data Intact
Revit IFC property set mapping is where many BIM exchanges either become dependable or quietly fail. Geometry may arrive in the coordination model, yet the data that makes a family useful—airflow, voltage, classification, manufacturer information, or a project-specific identifier—can be missing, duplicated, or placed under an unexpected property set. For a BIM manager, that is not a formatting defect; it is a handover and coordination risk.
This article explains how to design a repeatable mapping workflow for Revit families, with a focus on MEP content and information that must remain usable after export. It is aimed at professionals who need predictable IFC deliverables, not a generic introduction to Revit.
Why family data is lost in an IFC exchange
Revit and IFC do not store information in the same way. Revit parameters can be built-in, project, family, type, instance, or shared parameters. IFC organizes information through entities, attributes, quantities, classifications, and property sets. An export has to translate between those structures. If that translation is not deliberately configured, a value can be omitted even though it is visible in Revit.
Three common causes account for most surprises:
- Parameter ownership is unclear. A value intended for every placed diffuser may be defined as a type property, or the reverse.
- Names are inconsistent. Similar-looking parameters such as “Air Flow,” “Airflow,” and “Design Airflow” are not a controlled data standard.
- The exporter is configured too broadly or too narrowly. Exporting all Revit property sets can create noise and large files, while an unconfigured user-defined set can leave essential project data out.
Autodesk’s IFC export documentation distinguishes IFC common property sets, Revit property sets, schedules exported as property sets, and user-defined property sets. That distinction matters because each option serves a different purpose. A clean exchange specification should state which route carries each required field rather than relying on a default checkbox.
Build the information model before the mapping file
The best mapping file cannot repair an uncontrolled family library. Start with the information requirement from the receiving party: design coordination, quantity extraction, equipment schedules, facilities handover, compliance review, or a client data environment. Then build a small data dictionary for the families in scope.
| Decision | Example for an air terminal | Why it matters |
|---|---|---|
| IFC class | Appropriate air-terminal class and predefined type | Keeps downstream filtering and rule checking meaningful. |
| Parameter scope | Airflow as instance; model designation as type | Prevents repeated or misleading values. |
| Property-set destination | Standard common set or agreed custom set | Allows recipients to find data predictably. |
| Data type and units | Volumetric flow rate, not free text | Supports calculation, validation, and unit-aware viewers. |
Use shared parameters for fields that must retain the same definition across multiple projects and families. Autodesk notes that shared parameters can be used across both projects and families, and can be mapped through a shared configuration file for consistent IFC export. This makes them a strong foundation for controlled library content, although every shared parameter still needs a sensible name, scope, and purpose.
Separate type information from placed-instance information
A useful rule is simple: type properties describe the catalogue item; instance properties describe the placed object. Manufacturer, model reference, nominal dimensions, and a fixed performance class are usually type-level information. Room reference, installation height, tag, commissioning status, and a design airflow that varies by location are commonly instance-level information.
This distinction becomes especially important in MEP libraries. A controlled collection such as JebCAD’s air-terminal families for Revit can accelerate modelling, but the project team must still decide which values are fixed by family type and which are authored after placement. Treating every field as an instance parameter makes schedules harder to govern; treating every field as type data makes coordination less truthful.
Set up Revit IFC property set mapping deliberately
In current Revit workflows, the IFC export settings provide dedicated controls for common sets, Revit sets, schedules, and user-defined property sets. Autodesk’s IFC export setup reference is the practical baseline for deciding which controls are needed.
For repeatable project-specific data, use a user-defined property set. Autodesk documents two workable paths: newer releases provide a Manage Property Sets workflow, while earlier workflows use a tab-delimited text definition. In both cases, the principle is the same: name a property set, choose the applicable IFC classes, assign a data type, and map each IFC property to the exact Revit parameter name.
PVC AND PPR PIPE ACCESSORIES AND FITTINGS FAMILY AND OBJECTS FOR REVIT
A disciplined mapping sequence
- Choose the IFC schema and model view required by the appointment or client standard.
- Confirm the Revit category-to-IFC class mapping before adding custom properties.
- Freeze the parameter names in the data dictionary and remove accidental duplicates.
- Create a focused user-defined property set for only the fields the recipient needs.
- Map one class of representative family first, then test it in an IFC viewer.
- Store the configuration beside the project BIM documentation and version it with the delivery requirements.
Do not confuse the user-defined property-set file with the shared-parameters file. Autodesk specifically warns that selecting the wrong file in the IFC export setup prevents properties from being grouped as intended. Likewise, exporting all Revit property sets is useful for diagnosis but is rarely a good production default: it can introduce obsolete information and increase the export size.
How to test Revit IFC property set mapping
A mapping is not complete when the export finishes. It is complete when a recipient can inspect the intended IFC entity and recover the expected value, type, units, and grouping. Create a small test model containing one example of each family class, including at least two types and two placed instances where the data differs.
For every test object, record the expected entity, property-set name, property name, value, and unit. Then inspect the exported file in the project’s agreed viewer or validation platform. Test both the positive case and a deliberately blank or invalid case. Autodesk advises that parameters without values should not be assumed to export, which is another reason to validate populated exemplars rather than only the schema.
Checks that catch expensive errors early
- Verify that a diffuser, valve, equipment item, and fitting export to their intended IFC classes.
- Compare one type value and one instance value to confirm they have not been swapped or split unexpectedly.
- Confirm numerical fields use an appropriate typed value rather than a text string.
- Search for duplicate parameter names; Autodesk notes that duplicate names are not supported reliably in this export scenario.
- Check that the exported property-set names match the information-delivery specification exactly.
Industry impact: interoperability becomes a library responsibility
IFC is an open, vendor-neutral data model maintained by buildingSMART. That does not mean interoperability happens automatically. The quality of a coordination model increasingly depends on the design of the content library and its data contract, not only the final export settings.
For design teams, controlled mapping reduces the time spent explaining data to consultants and contractors. For contractors and owners, it improves the chances that schedule fields, classifications, and asset information arrive in a form that can be checked and reused. For library authors, it creates a clear feedback loop: a family that looks correct but cannot deliver its required data is not production-ready BIM content.
When building an MEP template, use consistent, well-tested source content. JebCAD’s PVC and PPR pipe fitting families and its Revit title-block collection are useful starting points for standardizing model and documentation content. Add the project’s shared parameters and IFC mapping rules before rolling those families out across live models.
Practical recommendations for BIM managers
Make the mapping file a controlled project deliverable. Give it an owner, a revision date, a change log, and a test model. Publish it with the BIM execution documentation so every author exports the same information structure. If a client changes a requirement, update the data dictionary and test pack before changing dozens of families.
Keep custom property sets lean. They should fill a documented information need that is not already met by the selected IFC common properties. This reduces ambiguity for downstream users and makes quality assurance faster. Above all, test the file with the receiving workflow rather than treating a successful export dialogue as proof of interoperability.
https://jebcad.com/design-category/architecture-hvac/
Summary
Revit IFC property set mapping turns a visually correct model into a dependable exchange deliverable. Define the information requirement, standardize shared parameters, separate type and instance data, map only what the recipient needs, and verify the result in an IFC viewer. That approach protects family data, strengthens coordination, and makes a BIM library more valuable across projects.
Need dependable Revit content for an MEP or architecture workflow? Explore JebCAD’s Revit Families and Architecture & HVAC library and establish the shared-parameter and IFC-mapping rules before the model moves into coordination.
FAQ
What is Revit IFC property set mapping?
Revit IFC property set mapping defines how Revit parameters are written into IFC property sets during export. It controls the destination property-set name, applicable IFC classes, data types, and source parameter names.
Should every Revit parameter be exported to IFC?
No. Export the properties required for the agreed exchange purpose. Broad exports can add obsolete information, create large files, and make data harder to interpret.
Why are shared parameters useful for IFC exports?
Shared parameters provide a consistent definition that can be used across Revit projects and families. They make it easier to map the same controlled field into an IFC property set across a library.
How do I validate an IFC mapping?
Export a small representative test model and inspect its entities and property sets in the project’s agreed IFC viewer or validation environment. Compare each required value, type, unit, and property-set name with the delivery specification.