Choose a suitable Revit family when you need to place and configure a native component in Revit. For model exchange between applications, consider the IFC version required by the project. Decide using the receiving application and required information, rather than treating the formats as interchangeable.
Start with the receiving task
A designer selecting a configurable product may need to change its type and report its reference code inside the authoring application. A coordinator receiving models from several disciplines may instead need a consistent exchange deliverable. Ask who will use the file, what they must change and which information must survive the handoff before selecting a format.
| Task | Candidate delivery | Acceptance check |
|---|---|---|
| Place and adjust a native component | A suitable Revit family | Host, types and parameters work in the target project |
| Exchange model information across tools | An agreed IFC delivery | Required objects and properties appear in the receiving tool |
| Support both authoring and coordination | Separate native and exchange deliverables | Product identity and revision match between files |
What IFC tells you, and what to agree
buildingSMART defines IFC as an open, vendor-neutral data schema, also standardised under ISO 16739. It represents model information and relationships, rather than simply naming a file extension. Agree the IFC version and exchange scope supported by both parties. A valid schema does not establish that all the information your particular project needs has been delivered.
Do not expect an exchanged file to reproduce every native editing control. Instead, list the outcomes the receiving user needs: product code, dimensions, location, material or another required property. Check those outcomes in the actual receiving application, not only in the exporting application's preview.
What to check in a Revit family
Revit distinguishes different family kinds; not every building element uses a loadable family file. For a supplied product component, ask which target version and hosting arrangement were tested. Open the file in a separate project and try the delivered types. A familiar extension or product preview is not evidence of compatibility with every project template.
A practical window handoff
Suppose the architect needs to place a window and the coordinator needs an exchange model. The architect checks the native file's width, host and product code. The coordinator checks the exported window's placement and agreed properties in the receiving tool. Both records reference the same manufacturer model and revision. If the code disappears during exchange, resolve the mapping before accepting the handoff; do not compensate by guessing from geometry.
- Write down the receiving application and supported delivery version.
- Select one representative product and one edge case.
- Check identity, units, placement and the required properties.
- Record differences and assign their resolution.
- Keep the accepted deliverables together with the test record.
The manufacturer data checklist helps define the information scope. Follow the object QA guide for a repeatable acceptance test, or browse BIMNESNE catalogue objects and inspect the files actually supplied for each product.
When downloading from BIMNESNE
Check the formats actually supplied on the product page. Do not assume every product includes both RFA and IFC files. Ask the manufacturer about missing formats or versions. Exporting an RFA component to IFC does not establish that native editing controls or every parameter will be retained.
Sources and editorial note
buildingSMART: Industry Foundation Classes and Autodesk: Revit families. The comparison and window example are BIMNESNE editorial guidance, not a promise that every product includes both formats. The cover is conceptual artwork.