Every architecture team that adopts Autodesk Forma for early-stage design eventually hits the same question: how does a Forma massing study actually become a working Revit model, without the team re-drawing everything from scratch and losing the climate and massing logic that justified the design in the first place? The honest answer is that the handoff works, but it has real seams — and knowing where those seams are before you hit them is the difference between a smooth transition and a frustrating afternoon of troubleshooting.
Autodesk’s supported mechanism for moving a Forma proposal into Revit is the Forma Add-In for Revit, currently labeled “Send to Revit (Beta)” in Forma’s interface. The workflow itself is straightforward: from within Forma, you open the proposal’s menu and select Revit > Send to Revit (Beta), which loads the proposal into a new Revit project. On the Revit side, the add-in surfaces under the Massing & Site tab, where you get control over which Forma elements actually come across and how they’re represented once they land in Revit.
What transfers through this path, according to Autodesk’s own documentation, includes:
Because the add-in sits under Massing & Site rather than arriving as a fully-detailed architectural model, the expectation should be set correctly from the start: what you get in Revit is a workable massing and site starting point, not a finished, fully-detailed building model. That’s by design — Forma is a conceptual tool, and the handoff is meant to preserve the conceptual geometry and site logic, not skip the detailed design phase entirely.
Beyond a one-way send, Autodesk’s documentation describes a round-trip capability: after sending a proposal to Revit and making changes there, you can update the Forma proposal to reflect those Revit-side changes, keeping the conceptual and detailed models loosely connected rather than permanently diverging the moment the handoff happens.
This is where teams should go in with realistic expectations rather than assuming it will behave like a flawless live link. Real-world reports on Autodesk’s own community forums describe specific friction: one documented case involved massing volumes failing to reappear in Forma after updating a proposal from changes made in Revit, serious enough that an Autodesk moderator requested the specific project and proposal IDs to investigate the bug directly. This doesn’t mean round-tripping doesn’t work — it means it’s a developing feature with known edge cases, and a team relying on it for an active project should test the specific round-trip behavior they need on a low-stakes proposal before depending on it for a live deliverable.
There’s a second thread worth knowing about, with an important caveat attached. Autodesk has described, including in an Autodesk University class on connected design workflows across Forma and Revit, a newer approach where data moves between the two platforms without a traditional file import/export step — closer to a persistent connection than a one-time transfer, including the ability to pull site geometry directly from Forma’s Data Marketplace.
How mature this is right now matters for how a team should plan around it. Autodesk’s own Forma blog describes this kind of integration as still developing, framing it as a direction the platform is heading rather than a fully shipped, stable capability — language that should read as “this is coming” rather than “this is production-ready today.” A team planning a real handoff workflow should treat the established Send to Revit add-in as the dependable path right now, and treat file-free, marketplace-driven integration as something to watch for in upcoming releases rather than something to build a current project’s workflow around.
| Method | What It Transfers | Maturity | Best Used For |
|---|---|---|---|
| Send to Revit (Beta) add-in | Proposal buildings, site limits, terrain, buildable areas | Documented, available now, explicitly labeled Beta | Standard handoff from a completed massing study into detailed Revit design |
| Round-trip update (Revit → Forma) | Syncs Revit-side changes back into the Forma proposal | Working but with known bugs reported by users | Keeping a conceptual model loosely aligned during early iteration, not as a guaranteed live link |
| File-free / Data Marketplace integration | Described as persistent data connection without import/export | Still developing per Autodesk’s own blog | Not yet recommended as a primary production workflow |
The high-level description of “send the proposal to Revit” skips over several decision points that are worth knowing before you click through them for the first time on a live project rather than a test file.
A few specific friction points come up often enough to flag directly, so a team isn’t troubleshooting them for the first time under deadline pressure.
This is a documented issue, not a rare edge case — a user on Autodesk’s own community forum reported exactly this (updating a proposal from Revit back to Forma, with massing volumes failing to appear), serious enough that an Autodesk moderator asked for the specific project and proposal IDs to investigate directly. If this happens, the practical response is the same one the moderator requested: capture the project and proposal IDs and raise it through Autodesk’s support channel rather than assuming it’s a one-off mistake in your own workflow.
Because the Send to Revit process generates a new project, coordinate system and project-base-point alignment between the new Revit file and any existing site survey data isn’t automatic — it’s worth checking alignment against known site reference points immediately after the handoff rather than assuming the geometry landed in the correct real-world position.
Because the add-in lets you choose which elements transfer, a common early-adoption mistake is bringing everything across by default and then spending time deleting or reconciling elements that duplicate work already done directly in Revit (terrain modeled from survey data being the most common case). Deciding deliberately what to include, rather than accepting every default, avoids this.
Beyond the technical steps, the handoff tends to go smoothly or badly based on a simpler factor: whether the team has actually agreed on who owns each side of it. A workable split looks like one person (often whoever led the conceptual massing work) owning the Forma proposal and deciding when it’s genuinely ready to send, and a separate person or team owning the Revit model from the point of handoff onward, responsible for turning massing into detailed, coordinated building elements. Without that clarity, it’s easy for a team to end up with both the Forma proposal and the Revit model being edited independently after the handoff, with no one tracking which one reflects the current design intent — exactly the scenario that round-tripping is meant to prevent, but can’t if no one is deliberately managing it.
Once a team is actively moving work between Forma and Revit — especially with round-tripping in the mix — file and version management stops being a minor housekeeping detail and becomes a real risk area if it’s not handled deliberately.
Rather than sending to Revit casually whenever a Forma proposal feels roughly ready, treat each send as a deliberate, named milestone — “Massing V2, sent to Revit [date]” — so that if questions come up later about which Revit model corresponds to which Forma proposal state, there’s a clear record rather than guesswork. This matters more than it sounds like it should, because the two platforms don’t share a single, unified version history the way, for example, Revit’s own worksharing does between team members on the same model.
Given the documented friction around round-tripping, many teams are better served by picking one platform as the authoritative source of truth after the initial handoff — typically Revit, once detailed design work has begun — and treating the Forma proposal as a historical record of the conceptual decision rather than something still being actively kept in sync. This sidesteps the round-trip reliability question entirely for teams whose workflow doesn’t strictly require live bidirectional updates.
The sun, shade, and wind analysis results that justified the massing decision in the first place are easy to lose track of once a team moves into Revit, where that analysis doesn’t automatically travel with the geometry. Exporting or archiving the key analysis outputs (screenshots, comparison summaries) alongside the handoff, rather than relying on being able to regenerate them from Forma later, preserves the design rationale in a way the geometry transfer alone doesn’t.
Most of the friction teams hit in this handoff isn’t really a software bug — it’s not knowing which parts of the workflow are solid, documented, and dependable versus which parts are newer and still maturing. Teams that understand the add-in’s actual scope, test round-tripping before relying on it, and plan for rebuilding detail rather than expecting a magically complete model save themselves real rework later.
Orbit Training Centre’s Autodesk Forma course in Dubai covers this handoff workflow directly — not just how to build a massing study in Forma, but how to carry it into Revit in a way that preserves the design logic instead of losing it at the handoff.
The broader lesson from this handoff workflow, and one that applies well beyond Forma and Revit specifically, is that moving between a conceptual tool and a detailed-design tool is never purely a technical export problem — it’s a process and ownership problem wearing a technical costume. Teams that get clear, in advance, on what the handoff actually transfers, who owns each side of it, and how the design rationale survives the transition tend to have a genuinely smooth experience. Teams that treat it as a one-click button press, without that groundwork, are the ones who end up troubleshooting round-trip bugs and missing geometry under deadline pressure instead of ahead of it.
No. It transfers proposal buildings, site limits, terrain, and buildable areas as a massing/site starting point under Revit’s Massing & Site tab — detailed architectural, structural, and MEP modeling still happens in Revit afterward.
The core Send to Revit add-in is documented and available, though explicitly labeled Beta. Round-tripping changes back to Forma has documented bugs reported by users, so test that specific capability on a non-critical proposal before depending on it for an active deliverable.
It’s a described direction where data moves between Forma and Revit without a traditional import/export step, including pulling site data from Forma’s Data Marketplace. Autodesk’s own blog frames it as still developing, so it shouldn’t be relied on as a current production workflow yet, and release notes should be checked periodically as this capability matures.
Test the specific update-back-to-Forma behavior you need on a low-stakes proposal first, since documented forum reports describe cases where massing volumes failed to reappear correctly after a Revit-to-Forma update.
Not necessarily, but understanding both sides of the handoff — what Forma is good at conceptually and what specifically transfers into Revit — is what makes the workflow efficient rather than frustrating.
There’s no single correct answer, but clarity matters more than the specific choice: assign one person to decide when a Forma proposal is genuinely ready to send, and a separate owner for the Revit model from that point forward, so the two platforms don’t end up being edited independently with no one tracking which model reflects the team’s actual, current design intent at any given point.
Sources consulted: Autodesk’s official Forma and Revit help documentation on iterative design and analysis workflows, Autodesk’s Forma blog on Revit hybrid workflows, Autodesk University class materials on connected Forma/Revit design, and user-reported issues on Autodesk’s community forums regarding round-trip updates.
