Create Revit Sheets from an Excel Register with Dynamo

On most projects the sheet list is agreed long before a single sheet exists in the model. It comes out of the fee proposal or the BIM Execution Plan, it lives in a spreadsheet, and it gets circulated to the client with numbers and titles already fixed. Then somebody opens Revit and types all of it in by hand.

For twelve sheets that is a mildly annoying afternoon. For a hundred and twenty it is most of a day, and it is the kind of work where a single transposed digit in a sheet number quietly propagates into the drawing register, the transmittal, and every reference on every sheet that points at it. The spreadsheet is already the source of truth. The sensible move is to have Revit read it.

That is exactly what this Dynamo graph does. It is short, it is about a dozen nodes, and once it exists you reuse it on every project you ever run.

The spreadsheet comes first, and it stays simple

The build starts in Excel, not in Revit. Two columns, one for sheet numbers and one for sheet names, populated and saved before Dynamo is even open.

That ordering matters more than it looks. The graph you are about to build is a translator, not an author. Every decision about what the sheets are called and how they are numbered stays in the spreadsheet, where the project architect can see it, the client can comment on it, and the BIM lead can check it against the naming convention. Nothing about the drawing register lives inside the Dynamo graph. Change the register, run the graph, get the sheets.

Keep the sheet structure flat and boring. One header row, one row per sheet, two columns, no merged cells, no blank rows scattered through the middle of the range, no colour coding that you are relying on to mean something. Dynamo reads cell values. It does not read your formatting.

Confirm the title block is loaded before you build anything

Revit opens on a brand new project with zero sheets in the Project Browser, which is the honest starting condition for this workflow. Then comes a check that is easy to skip and expensive to skip: the Project Browser is expanded into Families, then Annotation Symbols, to confirm a title block family is actually loaded. In this case an A1 metric title block.

Do this first. The sheet creation node needs a title block family type handed to it, and it can only offer you what the project already contains. A fresh project from a bare template may have no title block at all, in which case the node has nothing to select and the graph fails at the last step after everything upstream worked perfectly. Thirty seconds of checking saves a confusing five minutes of debugging.

If your office template is set up properly, the title blocks you use are already in it. If you find yourself loading a title block by hand at this point, that is a signal about the template rather than about the graph.

Open Dynamo from the Manage tab and start reading the file

Dynamo launches from the Manage tab and a new script is created. The first three nodes are the file reading chain, and they always look the same:

A file path node, which gives you a Browse button so you can point at the spreadsheet.
A file-from-path node, which turns that string path into a file object Dynamo can actually work with.
The Excel import node, which reads the workbook and hands back the cell values.

The file nodes go in first and get wired together, then the Excel import node is added and the file object is plugged into it.

The import node has a second input that catches almost everybody the first time: the worksheet name. Not the file name, not the workbook name, the name of the tab at the bottom of the Excel window. That input is set to the worksheet name at 1:43. If your tab is still called Sheet1, that is what goes in. If somebody on your team renamed it to Drawing Register, the graph needs Drawing Register and will return nothing at all for Sheet1. It fails quietly rather than loudly, which is what makes it worth knowing in advance.

Switch the graph to Manual before you go any further

The run mode is changed from Automatic to Manual, with the stated reason being that the nodes should not keep running on their own.

This is the single most important habit in this whole graph and it is worth understanding rather than just copying. Dynamo’s Automatic mode re-executes the graph every time you touch anything: add a node, change a number, move a wire. That is fine while you are doing arithmetic. It is not fine when the graph reads a file off disk and writes elements into a Revit model.

	Automatic	Manual
When it runs	On every edit	Only when you click Run
Reading a large spreadsheet	Re-reads constantly, feels sluggish	Reads once, when you ask
Building a model-writing graph	Can create elements mid-edit, before the graph is finished	Nothing touches the model until you decide
Half-wired graph	Runs anyway and throws errors	Sits still
Recommended here	No	Yes

Any graph that creates, deletes or modifies Revit elements should be built in Manual. Set it before you wire the creation node, not after.

Strip the header row, and read the preview instead of trusting the index

The import brings in everything, including the header row. You do not want a sheet called “Sheet Name”, so the header has to come out of the list. A list node is added that drops an item by index, fed from a Code Block holding that index. Double-clicking on empty canvas creates the Code Block, and the index gets typed straight into it.

Then something honest happens on camera. The expected index is 0, because Dynamo lists are zero based, and 0 is what goes in first. It does not give the result he wants, so it is changed to 1, which does. He says outright that he is not sure why, notes that Dynamo generally counts from zero, and moves on.

That is the right instinct and the wrong conclusion to draw from it. The lesson is not “sometimes Dynamo counts from one”. The lesson is that you should be reading what the node actually returns instead of assuming what it returns. Every node in Dynamo shows a preview of its output. Expand it, look at the shape of the data, count the entries, and confirm the header is gone before you wire anything downstream. When you skip that check, an off-by-one silently becomes a sheet named after a column heading, or a missing first sheet that nobody notices until the drawing register is compared line by line against the model.

Build the habit early: after every list operation, look at the preview. It takes two seconds and it removes an entire category of bug.

Transpose turns rows of data into columns of data

The imported data arrives the way a spreadsheet is shaped, as a list of rows. Each row is a pair: one number, one name. But the sheet creation node does not want pairs. It wants a list of all the numbers and a separate list of all the names.

A transpose node handles this, and the explanation given is the clearest one-liner for it: transpose flips rows and columns, so your rows become the columns and your columns become the rows. Run it and the data regroups: instead of many two-item lists, you get two long lists.

If you only remember one node from this graph, remember this one. Reading tabular data out of Excel and immediately transposing it is the standard opening move for almost every spreadsheet-driven Dynamo graph you will ever write, because spreadsheets are organised by row and Revit nodes are fed by column.

Pull the number column and the name column with Code Blocks

With the data transposed, the two columns are now two items in a list, and you pull them out by index. A get-item-at-index node takes the list, and a Code Block supplies the index. The Code Block syntax here is minimal: type 0; and that is the whole thing.

The second one is made by copying the first block with Ctrl+C and Ctrl+V and changing the index. Two nodes, two indices, two lists: one of sheet numbers, one of sheet names.

Which index gives you which depends entirely on the column order in your spreadsheet. Do not memorise it, read the preview. If index 0 is showing you strings like “GA-101” you have the numbers; if it is showing “Ground Floor Plan” you have the names. Getting these two swapped is the most common single failure in this graph, and it produces sheets that are individually valid and collectively useless, which is worse than an error.

The creation node needs four things, and one of them surprises people

The sheet creation node goes in at 4:11, and Dynamo offers more than one version of it. The variant used here is the one that takes views.

Its inputs are:

Sheet name, from one of your Code Block outputs.
Sheet number, from the other.
Title block family type. This does not come from the spreadsheet. A Family Types dropdown node is added and the A1 metric title block is selected from it. This is why the earlier check mattered: the dropdown lists what the project has loaded.
A view. The node requires a view input even though the goal here is to create the sheets themselves.

That last input is the one worth pausing on. Placing views onto sheets properly is called out as a meaningfully harder job than creating the sheets, and is deferred to a follow-up video. That is an accurate read of the problem. Creating a sheet is a single operation with three pieces of information. Placing a view on a sheet correctly means deciding which view goes on which sheet, at what scale, cropped how, positioned where, with the viewport type your office uses. It is a different graph with different logic, and trying to bolt it onto this one is how a clean twelve-node script turns into something nobody wants to maintain.

Treat sheet creation and view placement as two separate tools. This graph gives you a correctly numbered, correctly named, correctly title-blocked set of sheets, ready for whatever you do next.

Run it and watch the Project Browser fill

The graph runs and the Project Browser goes from empty to a full set of sheets. This is the moment worth internalising, because the time saving is not subtle. The whole build takes about five minutes on camera, and the run itself is instant. On a project with a hundred sheets, the graph does not take any longer than it did with twelve.

That is the actual argument for automating this particular task. It is not that Dynamo is faster than typing one sheet. It is that Dynamo is the same speed regardless of how many sheets there are, and it makes exactly zero typos.

What the video does not cover, and what you need to know anyway

Everything above is demonstrated. The following is not in the recording, and it is what you will hit on a live project the first week you use this graph.

Re-running is not an update. The creation node creates. It does not look for an existing sheet with that number and update it. Revit enforces unique sheet numbers, so running the graph twice against the same register does not give you a tidy refresh, it gives you errors or duplicates depending on the version and the node. Treat the graph as a one-shot setup tool for a new project, or as an append tool where you feed it only the new rows.

Adding sheets later needs a decision. When the register grows by six sheets in month four, the clean approach is a second, filtered spreadsheet, or a filter step in the graph that skips numbers already present in the model. Deciding that in advance is better than discovering it under deadline.

Excel node behaviour depends on the machine. Dynamo’s Excel reading has historically leaned on Excel itself being installed and available. On a machine without it, or in a locked-down environment, the import can fail for reasons that have nothing to do with your graph. If you are rolling this out to a team, test it on a standard workstation image rather than on the one machine where it was written, and know that a CSV-based read is the usual fallback.

Numbers stored as text will bite you. A sheet number like 101 may come out of Excel as a number rather than a string, and depending on formatting you can lose leading zeros or gain a decimal point. Formatting the number column as text in Excel is the simple fix, and checking the node preview is how you catch it.

Excel hygiene: the short list

Almost every failure in a spreadsheet-driven graph is a spreadsheet problem, not a Dynamo problem. Before you blame the graph:

The worksheet name matches the input. Tab renamed, graph broken.
One header row, at the top. Not two, not a title row above the headers.
No merged cells anywhere in the data range.
No blank rows inside the range. A gap becomes a null in the list and a null becomes a failed sheet.
No stray content below or beside the data. A note typed into a cell three rows under the table becomes a phantom row.
Consistent columns. Every row has both a number and a name.
Trailing spaces removed. "GA-101 " and "GA-101" are different strings, and the trailing space will follow the number onto the sheet.

Run a spreadsheet through that list once and it works every time after.

Where else this spine works

The structure of this graph is worth more than the graph itself. Strip out the specifics and what is left is a pattern:

read a file, clean the list, transpose it, pick off the columns you need, feed a create-or-set node.

That spine handles a large slice of the BIM data work firms do by hand:

Task	Same spine, different ending
Create levels from a floor schedule	Feed the elevations into a level creation node
Create and name grids	Feed coordinates and names into a grid node
Push project parameters in bulk	Feed names and types into a parameter node
Renumber doors or rooms from a list	Feed values into a set-parameter node instead of a create node
Place families at surveyed coordinates	Turn columns of X and Y into points

Once the reading and cleaning half is muscle memory, each new automation is only the last node. That is the real return on learning this one properly rather than downloading it. Our roundup of ten practical Dynamo automations for Revit covers several of these endings, and the wider documentation context sits in the guide to managing Revit sheets and views.

A note on versions

This was recorded in Revit 2019. The graph spine, file path into file object into Excel import, then drop, transpose, index, create, is unchanged in current Revit and Dynamo, and the concepts transfer directly.

What has moved around is the detail. Node names and their exact inputs have been renamed and reorganised across Dynamo releases, the Excel reading nodes in particular have changed behaviour and dependencies more than once, and there are now more variants of the sheet creation node than there were. So expect to search the node library for the current equivalent rather than matching the on-screen name character for character, and check what your version’s Excel node actually returns by reading its preview before you wire it up. That habit, again, is the one that carries across versions.

Common mistakes

Building it in Automatic mode. The graph fires while you are still wiring it and creates sheets you did not intend. Switch to Manual first.

Guessing indices instead of reading previews. Both the header drop and the column picks are index-driven, and both fail silently when the index is wrong. Two seconds of looking replaces ten minutes of confusion.

Swapping numbers and names. Sheets get created successfully with the name in the number field. Nothing errors. Check the preview against your column order.

No title block loaded. The graph is correct and the last node has nothing to offer. Check Annotation Symbols in the Project Browser before you start.

Expecting re-runs to update. The node creates. Feed it only rows you want created.

Keeping the register in two places. Once the spreadsheet drives the model, it is the register. Editing sheet names directly in Revit and forgetting the spreadsheet puts you back where you started, with two versions of the truth and no way to tell which is current.

Where to take this next

Build it once on a real project register rather than on a test file. Twelve rows out of an actual sheet list, run against an actual office template with your actual title block, will teach you more than a clean demo will, because your real register has the messy formatting that a demo does not.

Then keep the graph somewhere the team can reach it and treat it as a shared asset with a sensible name, not as a file in someone’s Downloads folder. The value compounds only if the next person does not rebuild it. The same habit applies to the rest of the project setup graphs: levels, grids and grid dimensions each follow the same read, transform, create shape, so one shared folder of four graphs covers a new project’s first morning.

If you want the documentation side of this in order rather than as one script, the complete Revit course on Archgyan works through sheets, views, title blocks and the drawing set the way firms actually issue them, taught by a working BIM Coordinator. Browse the courses and start with the documentation section.