--- title: Dynamo cleanup scripts need a rollback plan canonical: "https://subarashi.dev/posts/2026-05-27-dynamo-cleanup-scripts-need-a-rollback-plan/" pubDate: "2026-05-27T00:00:00.000Z" author: Ahmed description: "Ahmed explains why every Dynamo cleanup script needs a rollback plan before it touches live Revit models, parameters, views, or sheets." tags: [Dynamo, Revit, Workflow] --- Dynamo cleanup scripts are tempting because Revit models collect mess quietly. Duplicate views. Half-used parameters. Old sheets. Unplaced rooms. Stale imports. Worksets nobody wants to touch. Family names that started sensible and then grew barnacles. The script looks like relief. Select the targets, run the graph, clean the model, move on. That is exactly when the rollback plan matters. If a Dynamo graph can rename, delete, move, rebind, overwrite, or bulk-edit model data, then the graph is not just a convenience. It is a change operation. Treat it like one. ## The problem Cleanup scripts often run against symptoms, not systems. A model has messy views, so a script deletes views matching a pattern. A schedule has inconsistent values, so a graph rewrites a parameter. Families have naming drift, so a node chain renames types in bulk. The immediate result looks cleaner. The hidden risk is context. Maybe a view exists because a consultant still references it. Maybe a parameter value is wrong in one place but meaningful in another. Maybe a naming pattern catches types that should not be touched. Maybe a graph works in a copied test model but fails in the live central model because worksharing, permissions, or linked content changes the input set. The problem is not Dynamo. The problem is running irreversible cleanup without a recovery path. ## The rule of thumb Every cleanup graph needs three modes: - **preview:** show what would change - **commit:** make the approved changes - **rollback:** undo or restore the affected data If rollback is impossible, say that before the script runs. Then the decision becomes explicit: save a detached copy, export affected data, narrow the scope, or choose manual cleanup. The graph should never surprise the person who owns the model. ## The workflow Start with a target list, not a delete button. The safest cleanup scripts first produce a table: element id, category, current value, proposed value, reason, and risk. That table can be reviewed before anything changes. It also becomes the evidence trail after the run. Second, snapshot the affected data. For parameter rewrites, export element ids and old values. For renames, export old names and new names. For deletions, save a model copy and list the deleted element ids. For view or sheet cleanup, include view templates, sheet references, and whether the view is placed. Third, require an explicit commit step. A boolean toggle buried in a graph is not enough if the graph will touch hundreds of elements. Make the commit mode obvious and hard to trigger accidentally. Fourth, write the result. The script should report what changed, what failed, and what it skipped. A graph that silently completes is not proof that the model is healthy. Fifth, test rollback on a copy. Do not trust a rollback plan that has never been used. The first rollback should not happen during a deadline. ## What to watch for The first trap is broad filtering. String contains, category-only filters, and wildcard naming rules are useful, but they catch more than expected. If the script uses a broad filter, the preview table is not optional. The second trap is stale element ids. Revit element ids are useful inside one model state, but they are not a universal identity strategy. If the model has been audited, copied, upgraded, or heavily edited, confirm that your rollback reference still points to the intended elements. The third trap is deleting instead of quarantining. Sometimes the safer first step is to move views into a review prefix, place items on a temporary workset, or write a flag parameter. Deletion can come later after the team confirms nothing broke. The fourth trap is pretending undo is a rollback plan. Revit undo may help during a controlled session. It is not a governance strategy for a graph that touches shared work, saves, syncs, or triggers follow-on edits. The fifth trap is letting automation operate at a wider permission level than the person reviewing it. That is the same lesson as [designing AI agent permissions before tools](/posts/2026-05-27-how-to-design-ai-agent-permissions-before-you-give-them-tools/): scope the tool to the job, not to everything it can technically reach. ## A practical checklist Before running a Dynamo cleanup script on a live model, ask: - What exact elements can the graph touch? - Can it run in preview mode without writing? - Does the preview include old value, new value, and reason? - Is there a saved model copy or exported data snapshot? - Can the change be reversed without hand-editing every element? - Who approves the target list? - What happens if some elements fail? - Does the script write a result report? - Has rollback been tested on a copy? - Is the graph stored with the project notes so the next person knows what happened? If the answer to most of those is no, the graph is still a prototype. That does not mean you cannot use it. It means you should use it with prototype boundaries. ## Verdict Dynamo cleanup scripts are useful when they make Revit model maintenance safer, faster, and more repeatable. They become dangerous when they hide the blast radius. Preview first. Snapshot the affected data. Commit deliberately. Report the result. Test rollback before the model depends on it. Good automation does not just make the mess disappear. It leaves the team with a way back. -- Ahmed