Eighty-four sheets. Every one needs a number, a name, a title block, and a view landed in the right place on it. The numbering follows a field-by-field code from the BEP that nobody can recite from memory, so you keep the spreadsheet open on the second monitor and tab between it and the Project Browser like a man checking a boarding pass. It takes a day and a half. Then the volume codes change and you do most of it again.
That is a Dynamo job. Not an interesting one — no lofted surfaces, no attractor points, no image-to-geometry party trick. Just a machine that reads a list and types things into a database faster and more accurately than you can.
Dynamo Is a Data Clerk That Happens to Do Geometry
The reason most architects never get past the idea of Dynamo is that every tutorial thumbnail is a rippling facade. So you file it under "parametric", decide you are not that person, and carry on renaming views by hand.
But a Revit model is a database with a drawing view bolted onto the front. Sheets are records. Views are records. Doors and rooms are records with fields attached. Documentation, for the most part, is data entry with a graphic output — and data entry is exactly what visual programming is good at. We teach Dynamo through Lego blocks and a cake recipe for a reason: each node is one action, the wires carry data left to right, and the whole thing is a list of instructions you can read out loud. If you can describe the rule to a colleague in a sentence, you can usually build it.
The three jobs below are the ones that pay for themselves first on a real project. They are also the three we build from scratch in the Dynamo course, because they compound: each one feeds the next, and by the end they run as a single master script.
Job One: Sheets From the Spreadsheet You Already Have
The sheet list almost always exists before the sheets do. Someone has it in Excel — sheet number, sheet name, revision, who's drawing it. That spreadsheet is the input. Stop retyping it.
The graph runs backwards from its last node. Start with ViewSheet.ByNameNumberTitleBlock, hover over its inputs, and you have your shopping list: a name, a number, a title block family type, and optionally the views to place. Everything upstream exists only to feed those four sockets.
Number and name come from Data.ImportExcel, sliced into the two columns you care about.
Title block comes from a Family Type node — one dropdown, done.
Views come from whatever you've already got, or from the view script in Job Two.
The part worth thinking about is the number itself. If you are working to an ISO 19650-style code, the sheet number is not one string, it's a series of fields — project, originator, volume, level, type, role, number — joined with hyphens. The BEPs I've worked to define those fields explicitly, which is exactly why building the number in Dynamo is better than typing it. You build each field once, as a list, and combine them with a string node. When the volume code changes in month seven, you change it in one place and rerun. When you typed all eighty-four by hand, you don't.
One practical note: run this on an empty-ish sheet set. Dynamo will happily create a sheet with a number that already exists and hand you an error for its trouble. Filter your incoming list against the sheet numbers already in the model before you create anything.
Job Two: Views Renamed and Renumbered to Office Standard
This is the job that makes people believe. You've got levels, you need a floor plan and an RCP per level, each with the right view template, each named the way the office names things — not "Level 03 Copy 1".
The logic chain is short. Get all levels with All Elements of Category. Get their names. Create plan views from them. Apply the view template. Then build the view name by concatenating the level name with whatever your standard prefixes and suffixes are, and set it.
Renaming existing views is the same move with the front end swapped: instead of creating views, you collect the ones already in the model, transform the names as strings, and write them back. String operations sound abstract until you realise they are just find-and-replace with rules. Strip the first four characters. Replace "GA" with "General Arrangement". Pad the number to two digits. Sort by level elevation, then renumber in sequence.
Once plans, RCPs and sheets are all coming out of scripts, they can be wired to each other so floor plans land on floor plan sheets and RCPs land on RCP sheets — which is the actual promise of this workflow. Not "Dynamo renames things". Rather: the documentation structure of the project gets generated from the model's own data, consistently, in one run.
Job Three: Doors and Rooms, and the Parameters Nobody Wants to Fill
Door numbering is the purest example of a rule that a human does badly and a computer does perfectly. The rule is usually something like: the door takes the number of the room it opens into, with a suffix if there's more than one. Room parameters are similar — department, occupancy, finish codes, fire rating, all derived from something already known.
The writing end is the easy bit: Element.SetParameterByName, give it the elements, the parameter name as a string, and the values. The whole graph is upstream of that node, and it's all about getting the right value next to the right element in the right list order.
And this is where you meet Dynamo's actual difficulty, which is not coding. It's list structure. Lacing and list levels — whether one value goes to one element, or one value goes to every element, or lists pair up index by index — is the thing that makes a beginner's graph produce nonsense with no error message. Every Dynamo user has, at some point, set three hundred doors to the same fire rating and not noticed for a day. What we've found is that the fix is discipline rather than cleverness: put a Watch node before every write node and actually look at the list shape before you hit Run.
The other thing to plan for is nulls. A door that isn't bounded by a room, a room that's unplaced, a parameter that doesn't exist on that family. The graph hits it, throws a warning, and either stops or silently skips. Filter your list first — List.FilterByBoolMask on a null test — so you process the clean set and get a short list of the exceptions back. That exception list is genuinely useful output. It's a model audit you didn't ask for.
What Happens When It Fails Halfway Through 300 Sheets
Nobody writes about this, and it's the thing that actually stops people using scripts on live projects.
Here is what you need to know before you run anything on a model with other people in it. When a graph writes to the model, the elements it has already touched are touched. If the run dies at element 147, you have 146 renamed sheets and 154 original ones, and no tidy button. Revit's undo can sometimes pull the whole run back as one step, sometimes not — and that is not a coin flip you want to make on a Thursday deadline with someone else syncing into the central model.
So the habit we teach is boring and non-negotiable:
Test on a detached copy. Detach from central, discard worksets, run the script, look at the results, throw the file away. It costs five minutes.
Sync and reload before you run for real. Then run, check, then sync again immediately. Don't leave a scripted change sitting unsynced in your local while you go to lunch.
Don't run it while the team is mid-sprint on the same sheets. Anything your script touches, it needs to own. Element ownership conflicts in a worksharing model will kill a run halfway through, which is precisely the failure you're trying to avoid.
Write a reversal where the change is destructive. If a script renumbers sheets, also store the old numbers — dump them to Excel before you overwrite them. That spreadsheet is your undo.
One more: Dynamo Player is the right way to hand a script to the rest of the office, because the person running it never opens the graph and can't accidentally rewire it. But it also means they can't see the warnings. If a script is going into the Player, it needs to tell the user what it did — a text output, an Excel log, something — or you've just given your team a black box that fails quietly.
The Rule for When Not to Bother
Automating things is fun, which is dangerous. A script costs you the build, the debugging, the testing on a copy, and then maintenance forever — because packages update, Revit versions move on, and a graph authored in this year's Dynamo may not open in last year's on the project that's still running in it.
As a rule of thumb, write the script when three things are true:
The rule is describable in one sentence with no "except when". "Every door takes the number of the room it opens into." That's a script. "Mostly the room number, except on the escape corridors, and the plant rooms use the old consultant's numbering" is a script plus a manual pass, and the manual pass will take as long as doing all of it by hand.
The data already exists somewhere structured. A spreadsheet, a level list, a room parameter. If someone has to invent the values as they go, no script helps.
You'll do it more than once. Not more than once on this project — more than once ever. The first run rarely repays the build. The fourth project does, handsomely.
If you're renaming twelve views, rename twelve views. Nobody has ever been promoted for automating a five-minute job in ninety minutes. But if you're staring down eighty-four sheets, or a door schedule with four hundred rows, or the third time this year that an office standard has changed after the drawings were issued — that is when the graph is the cheap option.
And the scripts don't stay separate. Build them one at a time, then wire them into one master graph: levels to views, views to templates, templates to names, names to sheets, sheets to PDF. That's a morning's documentation setup collapsed into a button. Not because Dynamo is magic, but because you finally stopped doing the computer's job for it.
