Seeing RFA and IFC downloads beside the same product can make the choice look straightforward: pick the format your software opens. That overlooks what happens after opening. An architect changing a window type needs different capabilities from a coordinator checking where that window sits in a combined model. The two files may look almost identical on screen while serving quite different purposes.
Make the decision at the receiving end. Will someone adjust the component, use another team's model as a reference, extract product information or combine several disciplines? Which application and version will they use? Sometimes one file answers the need. Sometimes the useful delivery is a native component and an exchange model whose identities and revisions agree.
A Revit family contains more than its visible shape
RFA is the file format for a loadable Revit family; RVT is a project file. A family can describe relationships between dimensions, types and geometry as well as appearance. Changing a window width is a simple example: the frame, glass and opening leaf need to behave together. Autodesk's family documentation distinguishes loadable families from system families and elements created within a project.
When requesting a “Revit file,” explain whether you need a component to load or a project showing sample arrangements. The latter is not automatically a substitute for the former. Nor does a list of parameters establish useful configurability. Confirm how the available model types correspond to products the manufacturer actually supplies, and try the changes needed for your design.
Resolve the saved version early. Autodesk's compatibility guidance states that a family saved in a newer Revit version cannot be opened directly in an older one. Geometry obtained through a conversion is not equivalent to retaining the original family's editable relationships. Agreeing the project version before distributing a library avoids discovering this restriction at every workstation.
An IFC delivery needs an information brief
buildingSMART describes IFC as an open, vendor-neutral schema covering objects, properties and relationships in the built environment. It is standardised under ISO 16739. Product identity, materials and location can therefore form part of an exchange; IFC is more than a container for a 3D shape.
The format does not establish which information a particular file contains. Two teams may support the same IFC version yet expect different deliveries. One needs geometry for coordination; another also needs product references and specified technical properties. Complete “send an IFC” with the receiving application, supported version and required information. Otherwise, a disagreement over a missing field may really be a disagreement over what was requested.
| Receiving task | Starting point | First check |
|---|---|---|
| Configure a product in Revit | RFA in the target version | Types and hosting |
| Reference another discipline's model | Agreed IFC delivery | Position and visible scope |
| Review product references | IFC with specified properties | Code on the correct object |
| Support authoring and coordination | Native file plus IFC | Matching identity and revision |
One window, two acceptance decisions
Consider a window range with several widths. The architect needs to place suitable types in facade openings; the coordinator will combine the architectural delivery with other disciplines. Start with a typical window and a second size rather than preparing the whole facade before checking the exchange.
In a test project using the intended Revit version, the architect loads the family, places it in a suitable wall and changes its type. Does the selected product code follow the type? Do the frame and leaf change together? Does the stated width describe the same measurement as the technical drawing? Confusing a nominal width with a clear opening would compromise the comparison before anything is exported.
The coordinator asks different questions of the exchange file. Are both windows on the correct facade and storey? Can their product references be distinguished? Is an agreed material or performance value present on the relevant object? Successful editing in the native project does not answer those questions. Open the delivered IFC in the actual receiving application and inspect the same two windows there.
Suppose the geometry arrives correctly but both reference codes are empty. Remodelling the family is an unhelpful first response. If the source contains the values, investigate export scope and mapping. If it is empty too, obtain the manufacturer information first. These are different faults with different owners, although either might initially be reported as “the IFC is wrong.”
Trace properties through a small sample
A source field labelled “Reference” may appear under a different name in the receiver. Trace a recognisable value rather than comparing labels alone. Find product P-014 in the source, identify its field, then locate that value on the corresponding receiving object. Repeat with a differently coded product. The second example helps expose mistakes such as assigning one constant reference to every object.
Preserve physical meaning when comparing dimensions. A source value of 1200 mm and a receiving display of 1.2 m are not inherently inconsistent. Conversely, matching units cannot reconcile an overall frame measurement with an unrelated opening measurement. Establish the endpoints before comparing the numbers.
A small agreed set of identity, dimensional and technical fields is more useful than an unexplained collection of properties. The manufacturer product-data article shows how to define those fields. Also distinguish a missing property from an existing property with an empty value: the corrective work may occur at different points in the delivery process.
Linking an IFC is different from loading a family
An IFC link can provide a reference for further design work in Revit. Autodesk explains that the linked model is read-only and can be updated by reloading its source. Working against that reference is a different workflow from configuring a manufacturer's native component.
Hosting exposes the distinction. The same documentation notes that a wall-hosted door or window cannot be inserted into a linked IFC wall. If the wall is visible but placement fails, establish whether it is a native element or part of the link before blaming the component's dimensions. A correctly sized family cannot resolve the wrong placement context.
After replacing a link, revisit geometric references used by your work. Changed facade geometry may require measurements and alignments to be checked. A position corrected by an unexplained manual move is particularly troublesome at the next delivery. Agree the intended reference position with the supplying team so that subsequent users understand how the models belong together.
Make updates understandable to the recipient
A new timestamp tells the recipient little. Were two window widths revised, was a property mapping corrected, or was the entire model exported against another reference? A short change note directs attention to the right comparison. A dimensional change calls for geometry and placement checks; a data correction calls for checking the affected property. Changed export settings may justify looking beyond newly added objects.
Where the manufacturer supplies both RFA and IFC, make sure they describe the same product revision. An updated native file beside an old exchange file leaves users guessing which dimensions to trust. Keep the representative test products identifiable in both deliveries so comparison remains practical. The placement and troubleshooting article takes that sample into a project.
On BIMNESNE product pages, inspect the formats and versions actually offered; not every product supplies both. When requesting a missing file, include the receiving application and information requirements. That gives the manufacturer something more useful to work with than a request for another extension.