The first time most coordinators federate models from three different authoring platforms, something doesn't line up — a building that's floating above its site model, or a steel structure that's offset from the architectural shell by a suspiciously specific distance. Almost always, the cause is one of three things, and all three are preventable before you ever open Navisworks.
The most common cause: shared coordinates not actually shared
Revit, Tekla, and Civil 3D each have their own internal origin point, and unless a shared coordinate system has been deliberately established and used consistently across all three, "true north" and "project origin" in each file are independent fictions that happen to look fine in isolation and disastrous together. Before any federation work begins, agree on a single shared coordinate system — typically tied to real-world survey coordinates — and have every discipline publish from that same reference, not from "wherever felt convenient when the file was started."
Units mismatches that silently scale geometry
| Issue | What it looks like in Navisworks |
|---|---|
| Millimeters vs meters mismatch | A model appears 1000x too large or too small relative to others |
| Inconsistent rounding/precision settings | Elements appear to clash by a hair's width that isn't a real clash |
| Civil 3D survey units vs building model units | Site model and building model don't align even with correct coordinates |
Always confirm units explicitly on export/import rather than assuming Navisworks "figures it out" — it generally will import what you tell it to, including a wrong unit assumption, without necessarily flagging an obvious error.
Export settings that strip or distort geometry
Tekla and Civil 3D each have their own export plugins for Navisworks (NWC export), and default export settings sometimes simplify or omit detail that matters for coordination — reducing rebar detail in Tekla exports, for example, or generalizing terrain surfaces in Civil 3D in ways that hide real grading clashes. Review export settings deliberately for what level of detail your coordination actually needs, rather than accepting defaults built for file-size optimization. Once the federated model is clean, how you group disciplines into selection sets and clash rules determines whether the resulting clash report is actually usable.
A practical federation checklist
- Confirm all disciplines are working from one agreed shared coordinate system before modeling begins, not after.
- Standardize on one unit system across the project and verify it explicitly at each export.
- Test federation early — at the first design milestone, not for the first time right before a client coordination meeting.
- Re-verify alignment after any discipline re-publishes from a different shared coordinate reference (this happens more often than people expect when models get reset or recovered from a backup).
Why this is worth getting right early
A misalignment caught in week two costs an afternoon of fixing coordinate references. The same misalignment discovered the week before a client coordination milestone costs a re-export of every discipline's model, a delayed clash report, and an uncomfortable conversation about why the federated model "doesn't work." This is squarely a process discipline issue, and it's exactly the kind of thing an EIR should specify upfront on any multi-discipline project.
Multi-platform federation and shared coordinate setup are covered as part of the applied coordination project work in our Apex plan. Full curriculum on the Programs page.
