How Navisworks and Revit Work Together on a Real BIM Project

When I first got into BIM properly, I genuinely thought Revit and Navisworks were basically the same software. Like one was the newer version of the other. Both names kept coming up in the same conversations, and I assumed they overlapped so much it barely mattered which one people were talking about.

Working on an actual coordinated project changed that understanding completely. Once it clicked that they do completely different jobs, everything about the Navisworks and Revit BIM workflow started making sense. So here is the honest version of how they work together on a real project with real teams.

Revit Is Where the Building Gets Built

Every discipline on the project lives in Revit.

The architect builds walls, floors, roofs, openings, and stairs. The structural engineer puts together the frame,  columns, beams, slabs, cores, and foundations. Meanwhile, MEP consultants route ductwork, run pipework, place equipment, and lay out cable trays. Each discipline works in its own Revit file with its own families and data.

Those individual files are the raw material of everything that follows on a BIM project. Every drawing, every schedule, every quantity takeoff starts life in someone’s Revit model.

The Honest Limitation Nobody Talks About

Revit works really well within one file. It handles linked files reasonably well for basic coordination. Where it struggles is bringing four or five discipline models together and running proper coordination across all of them at once.

It was never designed for that. Trying to use Revit as your main coordination platform is a bit like doing project finances in a text document. You can push it so far and then it stops working properly.

That is exactly the gap Navisworks fills.

Navisworks Is Where the Coordination Happens

Here is the most important thing to understand about Navisworks. It also happens to be the thing that surprises people most.

Navisworks does not model anything.

Not a wall. Not a beam. Not one meter of ductwork. Instead, it takes models that other software already built and brings them into one place. Everyone can then see how the whole thing fits,  or does not fit,  before construction starts.

How the Export Cycle Works

On a real project, the workflow goes like this. Every discipline team maintains their Revit model throughout design. Every week or two, each team exports their Revit model to an NWC file. All those NWC files feed into one federated Navisworks model. That federated model drives all the coordination work.

Clash detection runs on that model. The coordination team reviews the results. The project team works through them together. Decisions land on who needs to move what. Each discipline takes those decisions back into Revit, makes the changes, and exports a fresh NWC. The cycle begins again.

That loop, Revit to Navisworks, decisions back to Revit, fresh exports back to Navisworks,  is the heartbeat of a properly run BIM workflow. It runs throughout design and often well into construction.

What Clash Detection Actually Feels Like

Let me be honest here because the polished version of this story does not prepare you for reality.

The First Report Always Looks Alarming

The first time clash detection returns five hundred results on a complex project, it feels like something went badly wrong. That alarm is misplaced, though. A large first clash report means the coordination process is working,  finding problems in a model rather than on a construction site with trades mobilized and a crane booked.

Navisworks shows where elements from different models share the same space. The judgment about which clashes actually matter belongs to the people in the room. The software identifies conflicts. Humans decide what to do about them.

How the Coordination Meeting Works

Some clashes are genuinely serious. A structural beam running through a main ductwork route needs resolving before either element goes near the site. Others are just noise,  two elements sharing a tiny overlap because of a modeling tolerance with no real-world meaning.

You get a feel for the difference quickly. Navisworks gives you filtering and grouping tools to bring the serious ones to the top.

After filtering comes the coordination meeting. The architect, structural engineer, MEP consultants, and usually the main contractor all sit together and work through the list. Who moves? Who redesigns? Decisions land, disciplines take assignments back to Revit, changes go in, fresh NWC exports go out, and the next round starts.

On a well-run project, that cycle runs until the model is clean enough that the construction team can trust what they see.

The Stuff Most Teams Never Bother With

Most teams use Navisworks for clash detection only. Genuinely valuable capability gets left behind as a result.

4D Simulation

4D simulation surprises people most when they actually try it. You connect the federated model to the construction programme and watch the build sequence play out over time. Sequence problems that nobody spotted on a Gantt chart show up on screen,  situations where the planned construction order creates access conditions that cannot physically work.

On phased construction or complex structural builds, this is genuinely useful. Not just impressive to show a client. Actually useful for planning.

Navisworks Freedom

Freedom is the free viewer version that anyone can download. Contractors, site supervisors, subcontractors, and clients can open the federated model without a Revit license. They can navigate the building, measure things, check clearances, and review coordination from their own perspective.

When site teams use the model during construction, the gap between what the model shows and what gets built shrinks noticeably. That gap is where many construction problems quietly live.

Where It Goes Wrong

Three things break this workflow more consistently than anything else. None of them are software problems.

Inconsistent Model Exports

The federated model is only as current as the last NWC export from each discipline. When someone falls two or three weeks behind, the coordination model shows stale geometry. Clashes that developed since the last update go undetected. A clear export schedule with named responsibility for each discipline is simply non-negotiable.

Treating Coordination as a One-Time Event

Running clash detection once at the end of design development is not this workflow. Design changes constantly. Disciplines update their models in response to each other. New clashes appear throughout the process. Regular coordination rounds running throughout design is what the workflow actually requires, not a single effort at the end.

Skipping the Meeting

A clash report sitting in someone’s inbox is not coordination. It is a list of unresolved problems waiting to surface on site. The workflow depends on the right people sitting together, working through results, making decisions, and owning resolutions. Without that conversation, the report means nothing at all.

The Simple Version

Revit is where the building gets built and documented. Navisworks is where the disciplines come together and the coordination work that prevents expensive site surprises actually happens.

When both tools are used properly,  regular exports, consistent coordination rounds, real meetings with real decisions, resolutions flowing back into Revit,  something genuinely good happens. The construction phase runs with fewer surprises. Trades arrive properly coordinated. The site team works from documentation that reflects what is actually being built.

Process discipline and consistency across every discipline makes it work that way. When it does work that way, it is one of the clearest demonstrations of what proper BIM actually delivers on a real construction project.

Ready to find out what your project will cost? Find out here.