How to Create Levels in Revit with Dynamo

A residential tower lands on your desk with forty two storeys at a 3.2m floor to floor, and the first thing anyone has to do in Revit is build the levels. Do it with the copy tool and you spend the next twenty minutes typing elevations into forty two separate level heads, then doing it again on Thursday when the structural engineer moves the transfer slab and every level above it shifts by 300mm.

Levels are the one piece of setup that nothing else in the model can proceed without. Walls constrain to them, floors sit on them, columns run between them, schedules group by them, and every plan view in the Project Browser is hosted by one. Getting them in quickly is useful. Being able to regenerate them in ten seconds when the grid of elevations changes is the part that actually saves a project.

The walkthrough below follows a real recorded lesson from the Archgyan Revit channel. Every step described as demonstrated is a step shown in the video, with links to the exact moment. The sections on naming, view creation, QA and team sharing are the parts a five minute recording cannot fit, and they are flagged as such.

Why this is worth automating when Revit already has a copy tool

Revit gives you two native ways to multiply a level, and the video demonstrates both before dismissing them. You can select a level in an elevation or section view and copy it upward against a reference, or you can use the array tool to produce a run of them at once, which is the faster of the two.

The objection raised in the video is the right one, and it is worth stating precisely because it is not “copying is slow”. Copying is quite fast. The problem is that you then have to open each level and set its height separately. An array gives you evenly spaced levels at whatever spacing you arrayed at, and the moment the real floor to floor differs from that spacing, or differs between the podium and the tower, you are back to editing level heads one at a time.

That is the difference worth understanding. The manual tools produce geometry. A script produces geometry from parameters you can change later. When the structural engineer moves the transfer slab, the copy tool user edits thirty level heads and the script user changes one number and hits play.

Start by fixing the base level, before you build anything

The video begins from File, New, Project using the architectural template, which arrives pre loaded with Level 1 and Level 2. Before any Dynamo work happens, those get cleaned up: delete the levels you do not need and rename Level 1 to Level 0, so the sequence you are about to generate starts counting from Level 1 rather than colliding with what the template supplied.

This is a small step that prevents a large mess. Revit will not let two levels share a name, so if your script generates a level that wants a name already in use, you get a duplicate name error or a silently unexpected result. Clearing the deck first means the generated set is the only set.

It also settles the ground floor datum question early. Whether Level 0 sits at 0mm, or at a finished floor level offset from the survey datum, is a project convention that belongs in the template rather than in a script. Decide it once, put it in the level you keep, and let the script build upward from there.

The two nodes that do the entire job

The graph is genuinely small. Open Dynamo from the Manage tab, start a new file, and you need exactly two nodes plus some sliders.

The first is Level.ByElevation. Searching for “elevation” surfaces it, and as the video points out while reading the node description, it creates a Revit level at a given elevation, and the name will be whatever Revit assigns it. Hold onto that second half. It is the script’s one real limitation and there is a section on it below.

The second is Sequence, found by right clicking on the canvas and searching, which is the general way to place nodes in Dynamo. Sequence generates a list of numbers from three inputs, and the video maps them straight onto the building:

Sequence input	What it means on the building
start	The base level elevation, where the stack begins
amount	The total number of levels to create
step	The floor to floor height

That mapping is the whole idea of the graph. A building’s level stack really is just a start, a count and a spacing, and once you have written it that way you can change any of the three without touching Revit geometry at all.

Feed Sequence into the elevation input of Level.ByElevation and the graph is functionally complete. Everything after this point is about making it usable by someone who is not you.

Slider ranges are part of the script, not decoration

Three number sliders drive the three Sequence inputs, and the video renames each one to base level, total number of levels, and height. Renaming matters more than it looks: these labels are what a colleague sees later in Dynamo Player, where the graph itself is invisible.

Then comes the step most beginners skip. A default Dynamo slider runs 0 to 100 in steps of 1, which is wrong for all three of these inputs. The video opens each slider and sets its min, max and step deliberately:

• Total number of levels: maximum around 100, step of 1. Whole levels only, and 100 is a sane ceiling.
• Height: the project units are millimetres, so a maximum around 6000 covers a double height space, with a step of 1000.
• Base level: given a working range in the low thousands with a coarser step, after the correction described in the next section.

Think of slider ranges as input validation. A slider that cannot express 3200mm as a floor to floor height is a broken script, and a slider that lets someone drag the height to 0.5mm is a script that will silently produce a hundred coincident levels. The ranges are where you encode what a legal answer looks like.

The units point deserves emphasis for anyone working imperial. Dynamo works in the project’s internal unit handling, and the numbers you type into these sliders are read in project units. A team working in feet and inches needs the height slider ranged accordingly, and mixing a millimetre habit into an imperial project is one of the fastest ways to generate a level stack that is off by a factor of twenty five.

The 1mm base level mistake is the most instructive moment in the video

The graph runs, and the elevations come out wrong. Dynamo is in automatic mode by default, so the result appears immediately, and the generated elevations carry an unexpected offset: values reading as 3001 rather than 3000.

The cause is diagnosed on camera. The base level slider was sitting at 1, and in a millimetre project that is a base elevation of 1mm rather than 0. Every level in the sequence inherited that 1mm, so the whole stack was a millimetre off the datum. The fix is to reset the base slider’s range and step so it can actually express the value you want.

This is worth dwelling on because a 1mm error is the worst kind. It is too small to see in a section view, too small to notice in a plan, and large enough to break things downstream. Floors placed on that level are 1mm off. Walls constrained top and bottom carry the error. A structural model linked in and copy monitored against your levels flags a mismatch that somebody spends an afternoon chasing. Dimension strings between levels start reporting 3001. And because Revit rounds display values according to the units settings, a level head can read 3000 while the underlying elevation is 3001.

The generalisable lesson: after the first run of any generative script, check one known value by hand before you trust the other forty. Pick the top level, work out what its elevation should be, and compare. It takes fifteen seconds and it catches exactly this class of error.

Switch to manual mode before wiring the final connection

Just before plugging the sequence into Level.ByElevation for the real run, the video switches the graph from automatic to manual. With the wire connected, the levels appear in the project.

Automatic mode is pleasant while you are building the numeric half of a graph, because you see the list update as you drag a slider. It becomes actively dangerous the moment a node writes to the Revit document. In automatic mode, every intermediate slider position you drag through is a transaction: drag the count slider from 4 to 41 and Dynamo will attempt to create and delete levels continuously on the way. On a small graph that is merely slow. On a graph touching hundreds of elements it will lock Revit up.

Make it a habit. Any graph containing a node that creates, modifies or deletes Revit elements goes into manual mode before that node is wired in. Build in automatic, write in manual.

Publishing the graph to Dynamo Player

A graph only you can run is a personal shortcut. A graph in Dynamo Player is a tool the team has, and this is where the video’s workflow gets genuinely valuable.

The mechanism is node level. Right click each slider and mark it as an input, and mark Level.ByElevation as the output. Those flags are what Dynamo Player reads to build its little form: the three sliders you renamed earlier become the three labelled fields a colleague fills in, and everything else stays hidden. Then save the graph and close Dynamo.

Dynamo Player reads its scripts from a designated folder, and the saved graph is copied into that folder so it shows up in the list. The video does not state a specific path on screen, and the location is configurable, so check the folder your own Player is pointed at rather than assuming one. In recent Revit versions Dynamo Player lets you browse to and pin a folder directly, which is what makes this workable for a team: point Player at a folder on the network or in your ACC-synced project directory and everyone gets the same scripts.

One practical gotcha shown in the video is worth repeating because it wastes people’s time. After copying a new graph into the folder, close Dynamo Player and reopen it before the script appears. Player builds its list when it opens and does not watch the folder for changes.

The last point made is the one to put in your team’s written procedure: always edit the input values before you press play, rather than running the script as it arrives. A Player script opens holding whatever values were saved with it, and running it unchanged means running someone else’s parameters against your project. The video closes by setting a new base, raising the level count and setting a new floor to floor height, then pressing play and getting an updated stack.

Copy, array, Dynamo or Player: pick per situation

Automation is not automatically the right answer. Choose by how many times the answer is going to change.

Approach	Best for	Cost	Reruns cleanly
Copy tool	2 to 3 levels, one off	Seconds	No
Array	An even run at a single spacing	A minute	No, heights still edited individually
Dynamo graph	Any tower, or any stack whose elevations are still moving	15 minutes once	Yes, change a slider
Dynamo Player	The same graph, used by people who do not open Dynamo	Zero after publishing	Yes, and safely

For a two storey house, open the copy tool and stop reading. The graph earns its fifteen minutes on repetition, either within one project because the elevations keep moving, or across projects because you built it once and it works on every job after this one.

What the script does not do

Two honest limitations, and neither is a flaw in the video’s method. They are properties of the node.

It does not name your levels. The node description read out in the video is explicit that Revit assigns the name. You will get Level 3, Level 4, Level 5 and so on, not the naming convention in your BIM Execution Plan. If your standard calls for L01 Ground Floor or 03_FFL, you need a rename pass afterwards. This is straightforward Dynamo work: get all levels, build the names you want with string operations, and set the Name parameter back. The pattern is the same as the batch view rename described in our ten practical Dynamo automations for Revit, and pairing the two into one graph gives you a level stack that is correctly named on creation.

It does not create plan views. This catches people constantly. A level created through the Revit API arrives without associated floor plan and ceiling plan views, unlike a level drawn by hand with the Level tool, which creates them by default. Your Project Browser will not fill up with new plans. Generate them afterwards in Revit through the Plan Views tool, which lists every level lacking a view, or extend the graph to create them. Either way, expect the extra step.

QA checks before you move on

Levels are load bearing for everything after them, so spend two minutes confirming them before you model a single wall.

1. Check one elevation by hand. Top level elevation should equal base plus spacing multiplied by the number of intervals. This is the check that catches the 1mm class of error.
2. Open a section or elevation view and look. Even spacing reads instantly, and any duplicate or coincident level shows up as a doubled level head.
3. Confirm the count. Levels created plus levels kept from the template should equal the storeys in the brief.
4. Check names against your standard before anyone constrains anything to them. Renaming a level later is safe in Revit, but it propagates into view names and sheet references, so earlier is cheaper.
5. Check which levels are story levels. Not every datum is a storey. Parapet, roof plant and intermediate structural datums may not want plan views at all.
6. Save the graph with the project, not just in your Player folder, so the parameters that produced this model are recoverable in six months.

Common mistakes

• Leaving the graph in automatic mode with a creation node wired in. The single most common way to hang Revit with Dynamo.
• Not setting slider ranges. A default 0 to 100 slider with a step of 1 cannot express 3200mm, and it invites nonsense values.
• Running a Player script without editing its inputs. You will generate somebody else’s building.
• Forgetting the template’s own levels. Delete or rename them first, or fight duplicate names later.
• Assuming plan views came along. They did not.
• Rerunning the graph to “update” levels. Running it again creates a new set, it does not move the existing one. To change an existing stack you either delete the generated levels first or write a graph that sets elevations on levels it collects rather than creating new ones.
• Sharing a graph without sharing the units assumption. A millimetre graph handed to an imperial project produces a very confident, very wrong answer.

Keep learning

The graph in this video is four nodes, and that is the point of starting here. Sequence into Level.ByElevation is the same shape as most useful Revit automation: describe the thing parametrically, generate it, then expose the parameters to people who should not have to open Dynamo. Grids, sheets, parameters and view sets all follow the same pattern.

If you are building out this side of your Revit work, the natural next steps are a rename pass so your levels arrive standard compliant, then the same treatment for grids, then sheets. Those graphs are written up as their own walkthroughs: creating and renaming grids with Dynamo reuses this slider and code block pattern, and dimensioning grids with Dynamo finishes the setup so the grid arrives on the sheet already dimensioned. Our Dynamo automations guide covers the wider set of tasks worth scripting and where the effort pays back.

For the structured path, from Revit fundamentals through to the coordination workflows firms actually run, see the Archgyan course library.