You have a sheet metal weldment with properly named cut list folders: meaningful names built from profile paths and custom properties, properly rolled up into your BOM. Then someone inserts that part into a parent weldment using Insert > Part, or you create a derived configuration that dissolves the cut list context — and every folder name silently reverts to “Sheet” or “Structural Member 1”.
This is not a bug. It is a consequence of how SolidWorks tracks cut list folder identity, and understanding the mechanism tells you exactly which fix to apply in which scenario.
Why Cut List Folder Names Are Not Stable
SolidWorks auto-generates cut list folder names from two sources:
- For weldment bodies: the profile path inside the structural member’s Library Feature Pack (the
.sldlfpfile). The folder name is derived from the profile library path, the member type, and sometimes a sequential index. - For sheet metal bodies: the feature name (“Sheet-Metal1”, “Sheet-Metal2”, etc.) or a default “Sheet” string.
Both names are considered auto-generated — they are not stored as static strings in the feature data. They are regenerated each time SolidWorks rebuilds the cut list. This works fine as long as the bodies stay in the file where they were created, because the profile reference is still intact.
When you use Insert > Part, something different happens.
What Insert Part Does to Cut List Context
The Insert Part command (Insert → Part, not Insert → Assembly) copies bodies from a source part into the current part. The source part’s bodies are “absorbed” — they exist in the destination file but are linked to the source via a derived part feature. The geometry comes across, but the structural member profile references do not.
SolidWorks cannot regenerate the profile-based name because the profile context did not transfer. It falls back to the generic naming logic:
- Weldment bodies without a profile reference → “Structural Member” followed by an index
- Sheet metal bodies without a feature reference → “Sheet” followed by an index
The same thing happens in three related workflows:
Derived configurations that suppress structural member features. If a configuration suppresses the Weld Member features but the bodies remain (via Instant3D or a keep-body feature), the auto-generated names have no feature to point at and reset.
Insert into New Part. This workflow takes selected bodies and deposits them in a new blank part file. The new file has no structural member history, so all cut list folders get generic names on first rebuild.
Dissolve subassembly at top level. If you dissolve a subassembly containing a weldment part, the cut list items surface at the top-level BOM but their identity now comes through a component path that may differ from the original — name collisions and unexpected resets follow.
Fix 1: Turn Off Auto-Update on the Folder Before Inserting
The most reliable prevention is to lock the folder name before performing any of these operations.
- In the FeatureManager, expand the Cut-List folder
- Right-click the cut list folder (e.g.,
Structural Member 1) → Properties - In the Cut List Summary tab, note that Auto-Update is checked
- Close Properties. Now right-click the folder again → Auto-Update (this is a toggle)
- When Auto-Update is off, SolidWorks stores the folder name as a static string rather than regenerating it from the profile reference
Now Insert Part, derive a configuration, or run any rebuild — the name stays.
The catch: turning off Auto-Update also freezes the cut-list properties (LENGTH, MATERIAL, etc.). If the source geometry changes, SolidWorks will not recalculate the derived properties for that folder. This is the right tradeoff if you are using the folder as a stable BOM item with a known identity, but it is the wrong tradeoff if the geometry is still in flux.
Fix 2: PARTNUMBER Property as the Merge and Identity Key
If you cannot lock Auto-Update (because the geometry is still live), use the PARTNUMBER custom property to give each cut list folder a stable identity that survives regeneration. This was covered in the context of cross-file BOM merging in SolidWorks weldment cut list combine: why filenames matter more than cut list properties, but it applies equally to the Insert Part scenario.
The PARTNUMBER property acts as the primary merge and identity key in the BOM. Even if the folder name regenerates to “Sheet” after a rebuild, the BOM row will use the PARTNUMBER value for its identity. Two rows with the same PARTNUMBER string will consolidate regardless of folder name.
Add PARTNUMBER on each cut list folder that needs to survive insertion:
- Right-click the cut list folder → Properties
- On the Cut List Summary tab, add a new property: Name =
PARTNUMBER - Value: either a literal (e.g.,
TUBE-50-50-3-L1500) or a computed expression using cut list property tokens (e.g., the DESCRIPTION and LENGTH properties joined with a dash)
The PARTNUMBER value persists through Insert Part because it is stored as a custom property on the folder, not derived from the profile reference. When the folder name resets, the PARTNUMBER survives.
Fix 3: The Rename-After-Insert API Macro
When you are dealing with an existing model where Insert Part has already run and the names have already reset, you need to rename the folders programmatically. Doing this manually for 40+ cut list items is slow and error-prone.
The SolidWorks API exposes cut list folders through IFeature::GetSpecificFeature2() which returns an ICutListItem2 interface. From there you can read custom properties and set the folder name.
Sub FixCutListNames()
Dim swApp As SldWorks.SldWorks
Dim swModel As SldWorks.ModelDoc2
Dim swPart As SldWorks.PartDoc
Dim swFeat As SldWorks.Feature
Dim swCLItem As SldWorks.CutListItem2
Dim swPropMgr As SldWorks.CustomPropertyManager
Dim sDesc As String
Dim sLen As String
Dim sNewName As String
Dim bRet As Boolean
Set swApp = Application.SldWorks
Set swModel = swApp.ActiveDoc
Set swPart = swModel
' Walk all features looking for cut list items
Set swFeat = swModel.FirstFeature
Do While Not swFeat Is Nothing
If swFeat.GetTypeName2 = "CutListFolder" Then
Set swCLItem = swFeat.GetSpecificFeature2
' Read existing custom properties from this folder
Set swPropMgr = swFeat.CustomPropertyManager
swPropMgr.Get5 "DESCRIPTION", False, "", sDesc, bRet
swPropMgr.Get5 "LENGTH", False, "", sLen, bRet
' Build a deterministic name
If sDesc <> "" And sLen <> "" Then
sNewName = sDesc & "-" & sLen
swFeat.Name = sNewName
End If
End If
Set swFeat = swFeat.GetNextFeature
Loop
swModel.ForceRebuild3 False
swModel.Save
End Sub
A few notes on this macro:
GetTypeName2 = "CutListFolder"is the reliable way to identify cut list folders, as opposed to checking the feature name (which is exactly what you’re trying to fix)IFeature.Nameis writable — assigning to it renames the folder in the FeatureManager- Setting the name this way does not automatically disable Auto-Update. The next rebuild may still regenerate the name. Call
swCLItem.SetAutoGenerated(False)to lock it: this is the API equivalent of turning off Auto-Update via right-click. - The
ForceRebuild3call withFalse(suppress save notification) is needed to flush the rename before saving
Fix 4: Derived Configuration Strategy
If your use case is a weldment with configurations that represent “as-welded” vs. “detail” vs. “simplified” states, derived configuration naming problems usually come from suppressing or unsuppressing structural member features between configurations.
The safer pattern:
- Keep structural member features active in all configurations
- Use Display State (rather than feature suppress) to control visibility
- If you must suppress members in simplified configs, add a cut list Manual Update step at the top of the config rebuild: right-click Cut-List → Update
This keeps the profile reference intact for name generation in every config.
For the “insert into new part” workflow specifically, consider whether you need it at all. If the goal is to break a large weldment into separate laser-cut parts for independent drawings, it is usually cleaner to work from a derived part (Insert → Mirror/Part with Link to Original) and export the flat patterns from there, rather than absorbing bodies. Batch DXF export from a SolidWorks assembly handles both assembly components and individual parts — keeping the source weldment intact avoids the naming problem entirely.
What Happens at Export Time
The practical consequence of a reset cut list name is downstream file naming breakage. If your DXF export tool names output files from the cut list folder name (or from a BOM property that sources from the folder name), reset names mean every exported file gets a generic name like Sheet_1.dxf, Sheet_2.dxf, and so on.
This compounds the problem documented in why your DXF flat pattern dimensions don’t match the folded part — not only are dimensions potentially wrong, but the output files are also unnamed, making shop floor routing impossible.
CadShift reads both the folder name and the PARTNUMBER property when building the export filename. If PARTNUMBER is set, it takes priority over the folder name, which is why the PARTNUMBER fix in Fix 2 above is the most resilient solution: even when a rebuild resets the folder name, the export file name stays correct because it comes from PARTNUMBER rather than the volatile folder name.
Checking the ICutListItem2 Flags Before Trusting a Name
If you are building a tool that processes weldment files and relies on cut list folder names, always check whether the name is auto-generated before using it:
Dim swCLItem As SldWorks.CutListItem2
Set swCLItem = swFeat.GetSpecificFeature2
If swCLItem.IsAutoGenerated Then
' Name was generated from profile path — will reset after Insert Part
' Read PARTNUMBER property instead
Dim sPNum As String
Dim bRet As Boolean
swFeat.CustomPropertyManager.Get5 "PARTNUMBER", False, "", sPNum, bRet
If sPNum <> "" Then
' Use PARTNUMBER as the stable identity
Else
' No PARTNUMBER set — fall back to folder name and document the risk
End If
Else
' Name was manually set or locked — safe to use directly
End If
IsAutoGenerated returning True is a reliable indicator that the folder name will not survive an Insert Part operation. Running this check in a pre-export validation step gives you early warning before files end up with broken names on the shop floor.
The SolidWorks batch DXF export tools compared post covers the broader landscape of export tooling — the naming reliability problem described here is exactly the kind of edge case that separates tools built on top of the SolidWorks API from VBA macros that read folder names directly without checking whether those names are stable.