Automating BIM Tasks

Naming conventions are the first casualty of a deadline, and fixing them by hand is soul-destroying. Scripting makes it reliable. A view's name is just a settable property, so renaming is a collect-and-loop with a string transformation in the middle. Suppose your team ended up with a pile of views prefixed Copy of and you want them gone:

count = 0
for v in views:                      # views collected earlier
    if v.Name.startswith("Copy of "):
        v.Name = v.Name.replace("Copy of ", "")
        count += 1
print(count, "views renamed")

Sheets work the same way, with two settable properties - SheetNumber and Name - so you can renumber a whole set to a prefix in one pass:

for s in sheets:
    s.SheetNumber = "A-" + s.SheetNumber

Both of these change the model, so remember the rule from the last lesson: they only run inside a transaction. In pyRevit you wrap the loop in with revit.Transaction("Rename views"):; in a Dynamo Python node you bracket it with TransactionManager.Instance.EnsureInTransaction(doc) and ...TransactionTaskDone(). Two honest cautions: names and sheet numbers must stay unique - Revit rejects a duplicate, so a blind prefix that collides will error, and you should skip or handle clashes. And test the string logic on a copy first; a replace with the wrong text can rename things you did not mean. Done carefully, though, a convention that took an intern an afternoon becomes a button that runs in seconds and never mistypes.

A subtlety worth flagging: not every view can or should be renamed the same way. A collector on views returns schedules, legends, sheets-as-views and templates alongside plans and elevations, so a blanket rename can touch things you did not intend. Filter to the view types you mean - by checking v.ViewType, or excluding templates with v.IsTemplate - before you loop. The same care applies to sheets, where placeholder and real sheets both appear. The habit is general and worth forming now - collect precisely, then rename - because most rename bugs are really selection bugs, fixed not in the string logic but in narrowing the set before the loop ever runs.

The single most useful BIM automation is writing the same parameter value across many elements - a fire rating on a wall type's instances, a phase on a batch of elements, a project code onto every sheet. It is the collect-loop-change pattern in its purest form. Here it is in a Dynamo Python node, which forces two habits worth seeing: unwrap the elements coming from the graph, and manage the transaction through Dynamo's TransactionManager:

import clr
clr.AddReference("RevitServices")
from RevitServices.Persistence import DocumentManager
from RevitServices.Transactions import TransactionManager

doc = DocumentManager.Instance.CurrentDBDocument
elements = UnwrapElement(IN[0])      # raw Revit elements
value = IN[1]                        # e.g. "2 hr"

TransactionManager.Instance.EnsureInTransaction(doc)
changed = 0
for el in elements:
    p = el.LookupParameter("Fire Rating")
    if p and not p.IsReadOnly:
        p.Set(value)
    changed += 1
TransactionManager.Instance.TransactionTaskDone()
OUT = changed

Three details make this robust. Guard for `None` - not every element has the parameter, and LookupParameter returns None when it is missing, which would crash the loop. Check `IsReadOnly` - some parameters are computed by Revit and cannot be set, so skip them rather than error. And `Set` expects the value in the parameter's type - a string for a text parameter, a number in internal units for a length, an integer 0 or 1 for a yes/no. Get those right and one node stamps a value across a thousand elements as easily as across ten - the leverage this whole course is about, aimed straight at BIM.

Automation is not only editing what exists - it can create. Tagging is the everyday example: dropping a tag on every door or room so a plan annotates itself. In the modern Revit API you create a door tag with IndependentTag.Create, which needs the document, the tag type, the view you are tagging in, a reference to the element, and a point. Conceptually the loop is: for each element, make a reference to it and place a tag near its location.

from Autodesk.Revit.DB import IndependentTag, Reference, TagMode, TagOrientation

# doors, tag_type_id, view, and t (a transaction) prepared earlier
for d in doors:
    ref = Reference(d)
    point = d.Location.Point            # the door's insertion point
    IndependentTag.Create(doc, tag_type_id, view.Id, ref,
                          False, TagOrientation.Horizontal, point)

The exact arguments shift a little between Revit versions - this is where you check the API docs for your release rather than trust an old snippet - but the shape holds: creation still happens inside a transaction, still one call per element in a loop, still driven by a collected set. Placing elements (a fixture at each grid intersection, a room-tag per room) follows the same rhythm. Two cautions: creation genuinely changes the model, so a mistake makes real objects you then have to delete - test on a copy and a small selection. And placement points matter; a tag created at the wrong point lands off the element. But once dialled in, self-annotating a plan of two hundred doors becomes a single click instead of an hour of careful clicking.

The highest-value BIM script often changes nothing. A BIM model is only as trustworthy as its data, and the quiet failure is missing values: doors with no fire rating, rooms with no name, sheets with no discipline. Auditing is a read-only collect-and-loop that produces a list of problems - safe to run any time, no transaction needed, and perfect to run before every issue.

missing = []
for el in elements:
    p = el.LookupParameter("Fire Rating")
    if p is None or not p.AsString():        # absent or empty
        missing.append(el.Id.IntegerValue)

print(len(missing), "elements missing Fire Rating")
OUT = missing                                 # a list of ElementIds

The pattern generalises to any completeness check: swap the parameter name, and you audit for blank room names, unassigned phases, or untagged doors. Returning the ElementIds is deliberate - in Dynamo you can feed that list into a Select.ByElementId node to highlight the offenders directly in the model, turning an abstract count into a visible to-do list a designer can fix. This is where scripting quietly changes a practice: instead of discovering a hundred blank parameters at the coordination meeting, a fifteen-line audit run every Friday surfaces them while there is still time. It is unglamorous, it makes nothing, and it may be the most valuable script in your kit - because catching missing data early is worth far more than any single bulk edit.

A script that only you can run, only when you remember how, delivers a fraction of its potential value. The leap that changes a practice is turning a working script into a tool - something a colleague clicks without knowing or caring that Python is underneath. Both hosts in this module support that leap, in different ways.

In Dynamo, a graph you save is already shareable: anyone with the file can open and run it. Better, Dynamo Player lets a user run a saved graph from a simple list, exposing only its inputs - pick a value, click play - with no canvas to understand. A missing-data audit or a batch-rename graph, dropped into a shared folder and run through Player, becomes a self-serve utility for the whole team. In pyRevit, the payoff is even more seamless: a .py script placed in the right folder appears as a button on a Revit ribbon tab, indistinguishable from any built-in command. Your audit becomes a button labelled "Check Marks" that a project architect clicks like any other tool.

Making a script tool-worthy asks a little more of it than a one-off does. Handle the empty and the awkward cases: what should the tool do if nothing is selected, or if a parameter is missing on every element? A one-off can crash and you shrug; a shared tool should report a clear message instead. Give feedback: print or show how many elements were changed, so the user trusts that something happened. Name the transaction descriptively, because the undo entry your colleague sees should read "Renumber sheets", not "transaction1". And guard the destructive paths - a tool that creates or deletes should confirm first, since the person clicking may never read the code.

There is judgement in when to make this leap, and it echoes this lesson's misconception. A script you will run once is not worth polishing into a tool; a check you run before every issue, or a rename your whole team needs, absolutely is. The cost is modest - a bit of error handling and a clear message - and the return compounds: every colleague who uses the tool multiplies the time your original hour of scripting gives back. This is how scripting stops being a personal trick and becomes practice infrastructure, and it is the natural destination of everything in this module - the collect-loop-change pattern, wrapped in a button, run by people who never see the code.