Within a team, having a file naming system is very important to have consistency. It is not only to make it look good but it is also to make your life easier when you need to modify someone else’s work. It improves readability and clarity as everything is formatted the same way. It also sets the path towards the integration with a file management system like SolidWorks PDM, miniPDM or company software like ERPs.
Preface
Changing a naming system is painful, I won’t lie, but once it is in place, it will save a lot of time for the team. The best way to define a naming system is to have as few rules as possible. The less rules you have the easier they will be remembered and followed by the users. Try to avoid special cases, sub-rules, different rules for different component classes and file types. See the article about the Definition of the Word Cocmponent.
The simpler the better
I have seen many ways to name the files in different companies. With a prefix, a mix of numbers and letters, some separators like hyphens or underscores, reserved ranges for sub-assemblies… The more it is complicated, the more people will make mistakes, typos. For purchased parts it is even worst than manufactured parts as people try to fit as much information as they can in the file name:
ManufacturerName-inductive-Sensor_M8.STAINLESS-STEEL_S4mm_harsh-environment.NPN.24V-pig_tail.sldprt
Speaking of prefixes, I have seen attempts to classify the components with it. Especially for purchased components. What seems to be a good idea becomes a nightmare when something belongs to more than one class up to the point that the rules are so complex, that it is not possible to cover all case scenario anymore.
Having project numbers in the file name works fine until you use the same component in different projects or you have some internal company standard components that don’t fall under a specific project.
All of this would be particularly difficult to automate with an algorithm to generate file names and even more difficult if you have to do it manually and remember all the rules…
Naming system requirements
- The naming system should be future proof with virtually unlimited names. If you use an incremental system with not enough digits, you can be limited to a reasonably attainable finite number of components.
For example if you use 3 chars for the project abbreviation followed by 3 digits representing the component number classified in assembly ranges of 100, 200, 300 you will have the following:

What if assembly “200” contains more than 99 parts? What do you do if another project abbreviation is ABC? How do you handle that?
- The naming system should have unique file names. It is one of the founding principles of databases: something should always have a unique key identifier.
This is not only true for a database but for a CAD library. With SolidWorks, there is a risk of mixing parts with the same names. If you open two different assemblies referencing two different files with the exact same name, the second assembly won’t load the second file but it will just use the first one already in memory. If it is a small component hidden deeply inside a big assembly and there are no mates errors to get your attention, you might miss it. If you save that second assembly, the link to the file will be definitely overwritten with the reference to the first file and won’t reference anymore the one that was supposed to go there! At least Windows prevents you from having two files with the same name when they are in the same folder but you probably have dozens of folders and sub-folders in your CAD directory so that won’t help much… Uniqueness is hard to keep over time.
If you design a bracket and name it Bracket.sldprt, how do you name a second bracket which is slightly bigger? BiggerBracket.sldprt? But what about someone else in the team working in a different folder not aware that you already created Bracket.sldprt? What about in 2 years when the team has drawn dozens of brackets? How to remember what combination has been already used?

- The naming system should have the same pattern for all classes of components.
For example, if you name the internal parts and the external components differently, you create complexity for the end user and increase the risk of mistakes.
- The information should appear just once. Often you have information in the filename and this information is repeated in some properties to appear in the Bill Of Materials, in the drawings, in the title-blocks, in the ERPs. Another founding principle of databases: the same information should only appear once to avoid mistakes and to be editable in one location. There are no reasons not to apply that principle to SolidWorks.
For example you have the following cylinder with this file name: Compact_Cylinder_25mm-The Vendor-EZF-5025-E2SV.sldasm

And you want to show in your BOM or in miniPDM, for example a Description, a Manufacturer and a Part Number column. See the article about the Component Properties. You will have to type again that information in the SolidWorks’ properties. If later you decide to change the stroke, the reference will be slightly altered, so you will have to change the Part Number property and the file name.
- The naming system should not use words. Words can be misspelled, the case rules are also very complicated to remember for the end user.

What was the rule again? How do you deal with units, sometimes it is upper case sometimes it is lower case sometimes it is mixed (Nm, Kg, etc…).
- The names should be short. Another issue is that SolidWorks can accept only a limited number of characters for the file path. If the file is located inside a lot of folders and sub-folders, having a long file name might reach that limit.

- The naming system should be flexible enough so changing something does not break links. In SolidWorks, if a file is renamed, an assembly using it won’t be able to locate it anymore. If that part is open you also have to close it first to rename it, which mean closing also all the assemblies referencing it and I am not speaking about the time it will take to reopen everything…
In the example with the cylinder, we are supposed to change the file name as we changed the vendor reference, that will most likely break the link with the containing assembly. In the end is twice the work to change the Part Number and the File Name, a risque of typo and links to repair!
On a side note, if you are using SolidWorks PDM, unique file names in the Vault can be easily enforced with a checkbox in the configuration (it is not completely true as an assembly and a part can have the same name since they have a different extension).
Solution
General
There is an easy way to fulfill all these requirements:
The file name should be a 10-digits incremental number. Period.
- It is a 10-digits number so it is future proof. You will be able to make 10 000 000 000 different components! Why 10? Because you can! To be sure to never reach the end of the range but also because for example with SolidWorks PDM, 10 digits is the maximum length that the serial number generator can handle. If you are using an automatic file name generator like the one present in miniPDM, you will also “burn” a lot of numbers for the components that you creates but never use in the final Bill Of Materials.
- It is an incremental number which insures uniqueness of the file names. Each time a new component is generated, that number is incremented and this regardless of the file type. Even if it is possible to have an assembly and a part inside the same folder with the same name because they have a different extensions, it should be avoided as it can create confusion and mess with your workflow if you use the file name for identification. You don’t want to have any risk of collision.
- Regardless of the class of component, internal or external ; the file names have the same pattern: a 10-digit number. One rule to rule them all!
- It is not used to store any relevant information. Everything is in the SolidWorks’ properties. If you modify something in the properties, the file name is not affected. You should also consider doing the same with configurations, see the article about the Configurations Naming.
- It is a series of figures without any meaning, it does not use any intelligible words. No letters means no headache to remember the case rule. No separators (- / _ / .) to confuse you even more.
- It is a 10 char long, which is quite short, so it does not consume much characters for the file path.
- It is just a box that can contain any classes of components to have flexibility. It could be an external component then you decide to make your own by using the 3D model so it becomes an internal component. Later you decide to make it a SolidWorks assembly as it has some internal movements and in the end you realize that you can make it a standard component. You can change your mind and just move the file around without having to change the way you name it.
So to sum up, in the end, instead of having the first line, you will have the second line:

Everything is there, just more flexible and consistent. OK, not everything, you loose some information about the Part Number and the Manufacturer, true. See the article about the Components Identification.
It is not possible to show other properties than the Description in Windows Explorer. See the article dedicated to Description Property to find out how to add it to Windows Explorer and SolidWorks’ construction tree.
If you have SolidWorks PDM you can add columns with any properties you want and use a search engine that look for a specific value of a property. You can also use SolidWorks Explorer to search for the properties and look at them for a specific component without opening SolidWorks. See the article about the Component Searching.
I know it is annoying but it is a fair trade to gain so much more. If you are quickly browsing with Windows Explorer, you don’t really need to know more than the Description anyway, especially if your folders structure is properly defined as you can narrow down easily to the right external component. For internal components it is more annoying as you might want to see the related drawing number in Windows Explorer. This is why using the file name as the drawing number is a good idea!
Furthermore, this unique file name, becomes your Document Number that you might want to show in your BOM or in your drawing. See the article about the Excel Add-in Settings to show it in miniPDM and create an hyperlink to it.
A document can contain multiple components thanks to configurations. Like a drawing that can contain multiple sheets to show different variations of a parts. See the article about the Component Configurations.
File Types
We discussed about the assembly files and the part files, but the naming system should be applied to everything that is related to a component. The point of entry is an assembly (SLDASM) or a part (SLDPRT), but then a drawing (SLDDRW) or a neutral CAD model (STEP, X_T, SAT, IGES, etc…) is made from it. Then from a drawing a print is usually created (PDF) and sometimes even 2D drawings (DWG, DXF).
Since all these files are related, they should all have the exact same name which is possible in Windows Explorer since they have a different extension.

Furthermore, they should be all in the same folder. See the article about the Folders Structure.
Implementation
The best time to switch from a legacy naming system to a new one is at the beginning of a new project and leave the old system as is. Renaming all your files would be a nightmare, just forget it! If there are several projects in parallel in the team, they probably won’t be all finished at the same time so you have to accept to have two naming systems coexisting for a while.
If some files needs to be re-used (standard parts, hardware, purchased components, etc…) they should be renamed to avoid having legacy files using the old system in a new project. That would look bad in a BOM. But you don’t want to break the links in the legacy assemblies using your old naming system.
You have two options to do it:
- If your standard components, hardware components, external components, etc… are in a specific shared network folder, just create a new one and everything that you create form now on goes in there.
- If they are not really classified in a particular folder or if you don’t want to create a new shared folder you will have to rename the files as you use them in new assemblies which will eventually break the links in the old projects.
The second option requires more work and discipline but it’s doable, it will just take a while to convert everything and maybe some components will never be renamed as they won’t be used anymore. In any case, you should take a look at the article on the Folders Structure to sort everything properly and efficiently.
You cannot just rename a component and keep all the links to their containing assemblies and drawings in Windows Explorer. You either need to do it with SolidWorks PDM or SolidWorks Explorer.
- In SolidWorks Explorer, click on a component and select the rename icon:

It will rewrites the links to that component where it is referenced.
Before renaming you should be sure to have all the information located in the file name copied to their respective properties.
This was a great write up. What is your suggestion for dealing with revisions of a part? Does the part file keep the same number but a revision number is added as a suffix, or do you issue a new part number for the new revision?
Hi,
Work fine for Mechanical projects but what about in the case of AEC projects ?
I often see Mechanical engineers starting AEC project as a Mechanical project. But it’s could be quickly the mess when you have many units/buildings with levels in a same site, with many disciplines (Electrical, Piping, etc…). One of the main problem i meet is AEC projects are often not divided by building and levels. In my case, i use the US National CAD Standards to define my AEC project files tree.
BR