Renaming Shared Parameters

Simple question… Can it be done??

1 Like

Best method is to create a new Shared Parameter with the changed name, copy the data from the old name to the new name, then remove the old Shared Parameter.

Thank you, but I was really hoping for something more efficient. I will hold out to see if anyone else has a way of doing it in Dynamo before I spend the time creating new ones and copying the data.

I don’t think so but the node SetSharedParameterByGUID should have been invented a long time ago.


Any given Revit project (RVT) uses the initial name stored with the GUID. Even if you renamed it manually in the TXT file, it would revert in your RVT file. While we can get the GUIDs from the Shared Parameters text file(s), it can’t be exposed in the API to manipulate attributes, such as the name. If that binding could be resolved, we could do a lot of things…

1 Like

It would be a great addition in Revit. An idea has been put forward, but would need much more votes.

You would not need this if the parameter could be selected by it GUID, the name is there to make it human readable. If its called “John” or “Erin” is not the important bit, but could lead to serious errors.

OK, so I have created the new Shared Parameters with the correct names. Can I transfer a parameter to another in dynamo instead of opening each family and assigning the new SP to the existing SP

I think FamilyDocument.AddSharedParameter from Orchid package is what you need to begin.

Forgive me if I am wrong here, but is that just to add a Shared Parameter? Sure it was quick to add them in Revit which I already done. I want to somehow get a parameter from a door family and change it to a new parameter.

why not add it to the Category instead, a lot easier and more freedom to Tag and create schedules from.
if its not driving geometry that is


Yes they are all driving geometry

there is also a node for adding parameter values in the Orchid package.
SetParameterByName and SetFormulaByName

According to changing names for shared parameters … that should always be very very hard to do, it is not at all a trivial process to do, I should only be for top experts to do. I know it is doable, and I have also done it, but I did consider it profound before I did it.

Problem is previously projects if you change the name in a shared parameter and projects are archived. What if they were connected by the parameter name, then the connection would be lost.

Before dynamo, it was difficult to copy values from one parameter to another, so this renaming options well hidden was an option know by experts. But with dynamo, where it is very easy to copy a value from one parameter to another I would NEVER do this renaming anymore, it is simply not the proper way to work.

Thank you
It would not effect any recent projects as I am still developing the template. I ended up creating the new SP’s and just opened every family and assigned the existing to the new, and once all new ones were assigned across all families and the template schedules, I just deleted the old ones. It took a while, but it’s done now.

I still think it should be straightforward to change the name though, regardless of whether it is best practice or not, especially since it was perfect for my situation. There just should be an error highlighting what you mentioned about previous projects. Errors can pop up many times in Revit for most people, and they choose to ignore them, so why should renaming SP’s be any different. I see mistakes happen everyday!

I will check out that node just to know for future reference. Out of curiosity, how did you change the name in the past?

There was the very well hidden trick with renaming the shared parameter, which I never shared with anyone, since it is absolutely not recommendable, no matter what. It is, in fact, a bit worrying that it can be done, it should not be allowed under any circumstances.

From a manager perspective for a company would this be the worst nightmare if anyone else than yourself knew how to do it. So no one at all should have the opportunity to do it. Also back in time has there existed other options when copying parameter values, export values to txt/csv/xclx files and import again are one option.

But with dynamo has it become so easy to do, so no one should be creative and rename shared parameters.

I would anytime vote against easy access to rename shared parameter as long as they are depended on GUID. I never hope Autodesk will consider that. I will even prefer if they closed the option totally to rename shared parameter.

1 Like

So you won’t tell me how you did it? There are many plausible reasons why one would need to change the name of a SP; there is my case, company and national standards changing, amongst others. If SP’s are mapped to a txt file, with each SP having a GUID, then is it not the case that the name is irrelevant? If you change the name, the txt file will update and any project linked to that file will update. (I may be wrong here, but it is my limited understanding)

It can not all be about Doom and Gloom. Like I said, there are mistakes made everyday with errors, etc. Its all down to proper management and proper training.

Like @echo said, copy the value from one parameter to the other, that is the proper solution.

Having an option to SetSharedParameterByGUID would also be doable as @Marcel_Rijsmus mention, since it goes on the guid and not the name whatever it might be. I am sure that I can build such a node, but such a node would only be for experts, so maybe not really needed since that kind of user always would be able to solve such problems.

Renaming SP is not a doable solution.


Yes that is what I done as I already mentioned. I copied everything. It still look a day of work to remap everything. There must be a simpler solution, and you have one so in order for me to become this so called expert, I would love to know it please. Either with being the node you could possibly create, or the way you done it in the past.

The nodes are present… that was what i described in my first post. Create a new SP parameter, named correctly. Get the values form the “old” parameter, put it on the “new” parameter, and then you are good to go. It can be done using my orchid nodes for families, and for projects use the OOTB nodes.

the below is a quick hack how it could look like
newSPparam.dyn (15.9 KB)


I would love to see the node Erik
And i wonder where the data goes if someone uses the add shared parameter option in the family environment and loads the family in a project where the same parameter has been set to the category the family is in. With all options like Type Parameter in the Family, Instance Parameter in the project and the other way around.

Maybe @erfajo can shed some light on this.