Revit will not rename a shared parameter — its identity is a GUID and the name is set the day it is born. So wrong names outlive projects, standards drift, and nobody dares touch the file. Rosetta renames shared parameters safely: same GUIDs, every value kept, a backup before anything moves.
A shared parameter's name is written into the SPF, bound into models, quoted in schedules and view filters. Revit offers no rename — only a new parameter, and a hole where the data was.
One grid, one mapping — and between you and the write: live validation that blocks errors, a dry-run report you can read first, and a backup that must exist before the file is touched.
Reload reads the active model and the shared parameter file together: bound shared parameters, project parameters, and the definitions that live only in the file. Kind, data type, group, scope — and an In use column that has already done the detective work. Filter by kind, search by name, group, category or data type.
| Current name | Kind | New name | Type | Group | Scope | In use | Status |
|---|---|---|---|---|---|---|---|
| FireRating | Shared | Text | Identity | Instance | 1 sched · 1 filter · 1 colour | ||
| AcousticRating | Shared | Text | Identity | Instance | 1 sched | ||
| Room Occupancy | Shared | Integer | Data | Instance | 1 sched · 1 colour | ||
| Sheet Series | Project | Text | Data | Instance | 1 sched |
Rosetta scans every schedule field — combined columns and embedded schedules included — every view-filter rule, however nested, and every colour-fill scheme. In use is not a guess; it is the list of exactly what breaks if you get this wrong. Lens reads the same audit: press Run on an element's Rosetta card and it says which of its parameters are shared, and where they are used.
| Current name | Kind | New name | Type | Group | Scope | In use | Status |
|---|---|---|---|---|---|---|---|
| FireRating | Shared | Text | Identity | Instance | 1 sched · 1 filter · 1 colour |
Each new name is checked live against Revit's naming rules, the whole file's final names — collisions after the rename, not before — and your office convention if you switch BIMIO naming on. Errors go red and block; warnings explain themselves. Or round-trip the mapping through Excel: Template… exports the file's parameters, a colleague fills the NewName column, Import… brings it back — the GUID, not the spelling, is the key.
| GUID | OldName | NewName | Group | Notes | |
|---|---|---|---|---|---|
| 2 | a1f4…9c2e | FireRating | BIMIO_FireRating | Identity | |
| 3 | 77b0…4d11 | Room Occupancy | BIMIO_Occupancy | Data | |
| 4 | c3e8…120f | AcousticRating | Identity | keep as is |
Dry-run touches nothing. It counts the elements holding a value for each rename, lists the schedules and view filters that depend on it, and hands you a self-contained report you can read, save or send — before you commit to anything.
| Old name | New name | Elements | Schedules | View filters | Notes |
|---|---|---|---|---|---|
| FireRating | BIMIO_FireRating | 214 | Door Schedule — L01 | FIRE-60 | |
| Room Occupancy | BIMIO_Occupancy | 63 | Room Schedule | ||
| DoorHardwareSet | BIMIO_HardwareSet | 0 | Not bound in this project (SPF-only rename). |
Rename SPF rewrites the shared parameter file — GUIDs untouched, a timestamped .bak saved beside it first; if the backup cannot be written, neither can the file. Rename in model goes further: it snapshots every value, rebinds each parameter under its new name and restores the values in one undoable transaction — re-pointing dependent schedules and view filters as it goes. Anything it cannot rebuild faithfully it refuses or skips, and says so. One failure and the whole gesture rolls back. Every operation lands in a history you can browse, with the backups a click away.
One feasibility matrix drives both the Convert dialog and the engine, so the window can never promise what Revit refuses. Ask for shared → project and it answers plainly: “The Revit API cannot create non-shared project parameters — no add-in can do this conversion.” Convert stays greyed; “Start assisted conversion…” appears instead, capturing every value, posting Revit's own Project Parameters dialog, and completing the swap when you press Finish assisted. What it can do outright is guarded as carefully: project → shared copies the values and re-points schedules and filters, but refuses while a colour-fill scheme or a global parameter still rides on the parameter.
Fill… stamps into a parameter something Revit knows about every element but never hands over as one: where it stands, which room it is in, what hosts it, which workset it is filed on. The picker offers only what can actually land — the categories are those the parameter is already bound to, “the only places it can be written”, and a value the target's data type could not hold is greyed rather than hidden, with the reason on hover: “A Length parameter cannot hold this value.” A type parameter is refused before the window even opens, because one value per type “would be wrong for all but one of them”. And it never pretends to be live: “This is a stamp, not a link.”
Nothing is written from the picker: it closes, Rosetta counts the whole job on Revit's own thread, and puts the numbers to you. “412 elements would be filled”, “48 already had a value and were kept (tick Overwrite to replace them)”, “77 have no such value in Revit”, “9 could not be written (6 owned by others, 3 read-only here)”. The dry run opens no transaction at all — a question that left an undo step behind would be lying about having changed nothing — and both passes run through the same per-element decision, so the count can never disagree with the write that follows it.
Sweep… converges a folder of .rfa files on the office standard, and Convert library stays locked until a dry-run of that exact folder has run — change the folder or untick “Include subfolders” and it locks again. The preview is per file and honest: what would become shared, what “matches the SPF but the data type differs — skipped”, and the one nobody thinks to check — “Saved in Revit 2019 — converting SAVES it as Revit 2026 (not openable in 2019).” Every modified file keeps a mandatory .rosetta-bak copy, no backup no conversion, and each family's type values and formulas are verified afterwards, with the family rolled back on any loss.
New… authors a shared parameter and binds it in one gesture. Bind… puts a batch of file definitions onto the model in one transaction. Convert… changes a parameter's kind wherever the API honestly allows — family to shared with every type value and formula verified afterwards, and a rollback if anything would be lost. Sweep… converges a whole folder of families on the file's standard, dry-run first and a backup per file. And Fill… stamps what Revit knows but never hands you as a parameter — coordinates, the rooms either side of a door, phases, sizes — into real parameters, counted and confirmed before a single write.
This is the misunderstanding that costs whole afternoons. A shared parameter lives in a text file; adding it there does not put it on anything. Revit has no way to add a parameter to a family already loaded into the project — that needs the Family Editor — and every other tool lets you believe otherwise until an app reports the parameter as missing and you cannot see why. Rosetta puts that in a banner, with the four steps that finish the job. When the parameter is one BIMIO itself owns, a second banner explains the part people get backwards: identity is the GUID, not the name, so renaming it is safe and tags travel between projects.
Binding a shared parameter asks two things, and Revit's own dialog is candid about neither. The first is instance or type, which everybody knows. The second only shows up months later: inside model groups, should every instance of the same group hold the same value, or may each one differ? Get it wrong and you find out when a value you edited in one flat appears in forty. Rosetta puts both questions on the screen in plain words, with the consequence written under each. And it will not pretend: a parameter you selected that is not in the current file cannot be bound at all, because binding needs the definition and the file is where it lives — so it says which ones, and skips them.
Rosetta rewrites the shared parameter file and rebinds parameters across a whole library — the kind of work that is fine until the one time it is not. So every destructive gesture records what ran, on which model, and the values it captured BEFORE touching anything. The shared parameter file itself is backed up on every write, and restoring a backup backs up the current file first, so the escape hatch cannot itself become the accident.
This is an actual HTML report Rosetta exports — self-contained, works offline, shareable as one file. Scroll it right here, or open it full-screen.
Rosetta ships on the Data panel of the BIMIO tab. Open your model, read the audit, and rename what has been misspelt for years — with a backup, a dry-run and a way back. Revit 2024–2027, full trial, no card.