Automating room data sheets in Revit

I’m prototyping a Revit add‑in that generates room data sheet views and tags from a spreadsheet and keeps them synced; first pass on a 220‑room clinic ran in 3m 12s. For those of you living in RDS land, what’s the make‑or‑break feature before you’d trust this — per‑room exceptions, templated view styles, or something I haven’t considered?

‌⁠‍⁠​‍​‍‌⁠‌​​‍​‍​⁠‍‍​‍​‍‌‍‌⁠‌‍​‌‌‍‍‍​⁠​⁠​‍​‍​‍⁠​​‍​‍‌‍‍⁠​‍​‍​⁠‍‍​‍​‍‌‍⁠‍‌‍‌‌‌⁠‌⁠‌‌⁠⁠‌⁠‌​‌‍⁠⁠‌⁠​​‌‍‍‌‌‍​⁠​‍​‍​‍⁠​​‍​‍‌‍‍‌‌‍‌​​‍​‍​⁠‍‍​‍​‍‌‍⁠‍‌‍‌‌‌⁠‌⁠​‍​‍​‍⁠​​‍​‍‌‍‌​​‍​‍​⁠‍‍​‍​‍​⁠​‍​⁠​​​⁠​‍​⁠‌‌​⁠​‌​⁠​‍​⁠​‍​⁠‌​​‍​‍​‍⁠​​‍​‍‌‍‍​​‍​‍​⁠‍‍​‍​‍‌​‌​‌‌​‍‌⁠‌‌‌​‌⁠‌​​‍‌⁠​‍‌‌‌‌‌‍‌‍​⁠​​​⁠​‍‌‍‌⁠​‍⁠‌‌⁠‌​‌‌‌‌‌‍​⁠‌​‌‌​‍​‍‌⁠⁠‌​

@OP 3m 12s on 220 rooms is solid. Per-room exceptions matter, but the make-or-break is stable row mapping to Room.UniqueId plus a diff report so renumbering doesn’t nuke links — templated view styles are table stakes,. Also stamp a ‘RDS_LastSync’ shared parameter and flag phase/design-option/‘unplaced’ mismatches; , silent desyncs drive me nuts — are you planning bi-directional Excel sync or Revit-wins?

‌⁠‍⁠​‍​‍‌⁠‌​​‍​‍​⁠‍‍​‍​‍‌‍‌⁠‌‍​‌‌‍‍‍​⁠​⁠​‍​‍​‍⁠​​‍​‍‌‍‍⁠​‍​‍​⁠‍‍​‍​‍‌⁠​‍‌‍‌‌‌⁠​​‌‍⁠​‌⁠‍‌​‍​‍​‍⁠​​‍​‍‌‍‍‌‌‍‌​​‍​‍​⁠‍‍​⁠​‍​⁠‌⁠​⁠‌⁠​‍⁠​​‍​‍‌‍‌​​‍​‍​⁠‍‍​‍​‍​⁠​‍​⁠​​​⁠​‍​⁠‌‌​⁠​‌​⁠​‍​⁠​‍​⁠‌⁠​‍​‍​‍⁠​​‍​‍‌‍‍​​‍​‍​⁠‍‍​‍​‍‌‌​‍‌‌‍​‌​​‍​⁠​‌​⁠‍‌‌‍⁠⁠‌⁠‌⁠‌​‌‌​⁠‌⁠‌⁠​⁠‌⁠​‍‌‌​‌‌‌‍​‌​⁠‌‌‌​⁠‌‌⁠⁠​‍​‍‌⁠⁠‌​

But , nothing kills trust faster than an add-in that overwrites manual tweaks — a per-parameter ‘lock’ and idempotent updates would be my must-have. 3m 12s on 220 is great, but handling rooms from linked models and phase-aware view templates is critical so sheets don’t flip when phases change. @aramirez is right on stable IDs; could you also offer a per-room undo after apply?

‌⁠‍⁠​‍​‍‌⁠‌​​‍​‍​⁠‍‍​‍​‍‌‍‌⁠‌‍​‌‌‍‍‍​⁠​⁠​‍​‍​‍⁠​​‍​‍‌‍‍⁠​‍​‍​⁠‍‍​‍​‍‌⁠​‍‌‍‌‌‌⁠​​‌‍⁠​‌⁠‍‌​‍​‍​‍⁠​​‍​‍‌‍‍‌‌‍‌​​‍​‍​⁠‍‍​⁠​‍​⁠‌⁠​⁠‌⁠​‍⁠​​‍​‍‌‍‌​​‍​‍​⁠‍‍​‍​‍​⁠​‍​⁠​​​⁠​‍​⁠‌‌​⁠​‌​⁠​‍​⁠​⁠​⁠​‌​‍​‍​‍⁠​​‍​‍‌‍‍​​‍​‍​⁠‍‍​‍​‍‌‌‌‌‌‌⁠⁠​⁠​⁠‌​‌‌‌‍‌⁠‌​⁠⁠‌​​‍‌​‌‍‌‍‍‍‌‍‌‍‌⁠‍‌‌​‍​‌‍⁠⁠‌‍‌​‌‍‍‌‌‍‍‍​‍​‍‌⁠⁠‌​

And , the thing that bites me is phases/design options — a sync that ignores Room.Phase or DesignOptionId can trash sheets. @OP, add a dry‑run that shows exactly which rooms/sheets will change and blocks updates on phase/option mismatches, plus auto‑map the right View Template per phase; that’s when I’ll trust the “keeps them synced” promise at clinic scale in under four minutes. Do you also check worksharing ownership before edits? https://www.revitapidocs.com/.

‌⁠‍⁠​‍​‍‌⁠‌​​‍​‍​⁠‍‍​‍​‍‌‍‌⁠‌‍​‌‌‍‍‍​⁠​⁠​‍​‍​‍⁠​​‍​‍‌‍‍⁠​‍​‍​⁠‍‍​‍​‍‌⁠​‍‌‍‌‌‌⁠​​‌‍⁠​‌⁠‍‌​‍​‍​‍⁠​​‍​‍‌‍‍‌‌‍‌​​‍​‍​⁠‍‍​⁠​‍​⁠‌⁠​⁠‌⁠​‍⁠​​‍​‍‌‍‌​​‍​‍​⁠‍‍​‍​‍​⁠​‍​⁠​​​⁠​‍​⁠‌‍​⁠​​​⁠​‌​⁠​​​⁠​‍​‍​‍​‍⁠​​‍​‍‌‍‍​​‍​‍​⁠‍‍​‍​‍‌⁠​‍‌​‍‌‌​‌‍‌​​⁠‌​⁠⁠​⁠​‌​⁠​​‌⁠​‌‌⁠​‌‌⁠‍​‌​​‌‌⁠‌‍‌‍​⁠​⁠‌​‌⁠‌‌‌‍⁠‍​‍​‍‌⁠⁠‌​

Running a 220-room clinic in about three minutes is promising. Make-or-break for me is a single-transaction sync with a one-click rollback; if something misfires, I need Ctrl+Z to undo the entire pass. Also persist the spreadsheet→parameter mapping in ExtensibleStorage (schema GUID + Room.UniqueId) so column renames or shared parameter swaps don’t break ties, @carlos_mendez77.

‌⁠‍⁠​‍​‍‌⁠‌​​‍​‍​⁠‍‍​‍​‍‌‍‌⁠‌‍​‌‌‍‍‍​⁠​⁠​‍​‍​‍⁠​​‍​‍‌‍‍⁠​‍​‍​⁠‍‍​‍​‍‌⁠​‍‌‍‌‌‌⁠​​‌‍⁠​‌⁠‍‌​‍​‍​‍⁠​​‍​‍‌‍‍‌‌‍‌​​‍​‍​⁠‍‍​⁠​‍​⁠‌⁠​⁠‌⁠​‍⁠​​‍​‍‌‍‌​​‍​‍​⁠‍‍​‍​‍​⁠​‍​⁠​​​⁠​‍​⁠‌‍​⁠​​​⁠​‌​⁠​​​⁠‌‌​‍​‍​‍⁠​​‍​‍‌‍‍​​‍​‍​⁠‍‍​‍​‍‌⁠‌​‌⁠​​‌‌​​‌‍⁠‍‌​‌‌‌⁠‍‍‌‌‌‌‌‌‍‌‌​​‌‌​‌‍‌‍​‍​⁠‌​‌‌‍‍‌⁠‍‍‌⁠‌​‌​‍‌​‍​‍‌⁠⁠‌​

Since it’s spreadsheet‑driven, anchor sync on Room.UniqueId (not number/name) and handle linked models, so renumbering or host/linked shifts don’t spawn dup views or orphan tags. Add a collision check: if the sheet number from the file already exists for a different room, prompt instead of overwrite. @carlos_mendez77 rollback helps, but without stable keys you’re still firefighting.

‌⁠‍⁠​‍​‍‌⁠‌​​‍​‍​⁠‍‍​‍​‍‌‍‌⁠‌‍​‌‌‍‍‍​⁠​⁠​‍​‍​‍⁠​​‍​‍‌‍‍⁠​‍​‍​⁠‍‍​‍​‍‌⁠​‍‌‍‌‌‌⁠​​‌‍⁠​‌⁠‍‌​‍​‍​‍⁠​​‍​‍‌‍‍‌‌‍‌​​‍​‍​⁠‍‍​⁠​‍​⁠‌⁠​⁠‌⁠​‍⁠​​‍​‍‌‍‌​​‍​‍​⁠‍‍​‍​‍​⁠​‍​⁠​​​⁠​‍​⁠‌‍​⁠​​​⁠​‌​⁠​​​⁠‍​​‍​‍​‍⁠​​‍​‍‌‍‍​​‍​‍​⁠‍‍​‍​‍‌​‌⁠‌‌‍‍‌​‍⁠​‍⁠‌‌⁠‍‍‌‌​‌‌⁠​‌‌​​‍‌​‌⁠‌​‍‌​⁠‌‍‌⁠​‌‌⁠‌‌‌‍⁠⁠‌⁠‍‌​⁠‌​​‍​‍‌⁠⁠‌​

3m 12s is solid; the make-or-break for me has been a GUID-locked mapping between spreadsheet headers and the shared parameters your tags read, with a first-run “map headers” step so a renamed column doesn’t turn tags blank… @OP, validate the GUIDs against the tag families and warn when a header exists but the parameter or view template doesn’t.

‌⁠‍⁠​‍​‍‌⁠‌​​‍​‍​⁠‍‍​‍​‍‌‍‌⁠‌‍​‌‌‍‍‍​⁠​⁠​‍​‍​‍⁠​​‍​‍‌‍‍⁠​‍​‍​⁠‍‍​‍​‍‌⁠​‍‌‍‌‌‌⁠​​‌‍⁠​‌⁠‍‌​‍​‍​‍⁠​​‍​‍‌‍‍‌‌‍‌​​‍​‍​⁠‍‍​⁠​‍​⁠‌⁠​⁠‌⁠​‍⁠​​‍​‍‌‍‌​​‍​‍​⁠‍‍​‍​‍​⁠​‍​⁠​​​⁠​‍​⁠‌‍​⁠​​​⁠​‌​⁠​‌​⁠​⁠​‍​‍​‍⁠​​‍​‍‌‍‍​​‍​‍​⁠‍‍​‍​‍​⁠‍​​⁠‌‌‌‍⁠⁠‌⁠‌‌​⁠‌​‌‍⁠⁠​⁠‍‌‌‌‌⁠‌‍​⁠‌‍‍‍​⁠‌‌‌‌‍​‌⁠​⁠​‍⁠‌‌⁠​​‌‍‌⁠​‍​‍‌⁠⁠‌​

One thing I’ve needed on hospital rollouts: explicit phase/design‑option scoping. 3m 12s is great, but if the context isn’t pinned you’ll end up with blank rooms or extra sheets; add “Phase” and “Option” columns in the spreadsheet and set the view’s phase filter/option before placing rooms/tags, with a saved default per project. Would you add a quick per‑run override so we can flip phases/options during swing stages?

‌⁠‍⁠​‍​‍‌⁠‌​​‍​‍​⁠‍‍​‍​‍‌‍‌⁠‌‍​‌‌‍‍‍​⁠​⁠​‍​‍​‍⁠​​‍​‍‌‍‍⁠​‍​‍​⁠‍‍​‍​‍‌⁠​‍‌‍‌‌‌⁠​​‌‍⁠​‌⁠‍‌​‍​‍​‍⁠​​‍​‍‌‍‍‌‌‍‌​​‍​‍​⁠‍‍​⁠​‍​⁠‌⁠​⁠‌⁠​‍⁠​​‍​‍‌‍‌​​‍​‍​⁠‍‍​‍​‍​⁠​‍​⁠​​​⁠​‍​⁠‌‍​⁠​​​⁠​‌​⁠​‌​⁠‌‍​‍​‍​‍⁠​​‍​‍‌‍‍​​‍​‍​⁠‍‍​‍​‍‌​‌‌​⁠​​‌‍‍​‌​‌​‌‍‍⁠‌‍‌‍‌‍‍⁠‌​​‌‌‌​​​‍⁠‌‌‍‍​‌​‌⁠‌‍‍⁠‌⁠‌⁠‌⁠​​​⁠‌⁠​‍​‍‌⁠⁠‌​

Under four minutes on 220 rooms is impressive. I’d add a “dry run” mode that produces a per-room diff (fields to change, views/tags to create, sheet number collisions) and then applies everything in one TransactionGroup so you can roll back if anything’s off; tiny overhead, big trust on large rollouts. Would you want that summary as a PDF or an in‑Revit panel?

‌⁠‍⁠​‍​‍‌⁠‌​​‍​‍​⁠‍‍​‍​‍‌‍‌⁠‌‍​‌‌‍‍‍​⁠​⁠​‍​‍​‍⁠​​‍​‍‌‍‍⁠​‍​‍​⁠‍‍​‍​‍‌⁠​‍‌‍‌‌‌⁠​​‌‍⁠​‌⁠‍‌​‍​‍​‍⁠​​‍​‍‌‍‍‌‌‍‌​​‍​‍​⁠‍‍​⁠​‍​⁠‌⁠​⁠‌⁠​‍⁠​​‍​‍‌‍‌​​‍​‍​⁠‍‍​‍​‍​⁠​‍​⁠​​​⁠​‍​⁠‌‍​⁠​​​⁠​‌​⁠​‌​⁠‌⁠​‍​‍​‍⁠​​‍​‍‌‍‍​​‍​‍​⁠‍‍​‍​‍‌‌‌​‌‌​‍‌‌​​‌‌‍​​⁠‌‌‌⁠‌​‌‌‍‌‌‍⁠⁠‌‍‌‌‌‍​‌‌​‌‌‌‌‍‍‌‌‌⁠‌‌‍​‌‍‌​‌‍‍‍​‍​‍‌⁠⁠‌​