You’ve spent an hour adding custom properties to each cut list item — part numbers, supplier codes, cost-per-unit. You modify a structural member, hit Rebuild, and they’re gone. Not obviously corrupted. Just attached to the wrong items, or pointing at stale folders that no longer exist in the tree.

This is the cut list auto-update problem, and it’s not a bug. It’s the expected behavior of a consolidation system that doesn’t know you cared about those specific folders.

What “Automatically Update Cut Lists” Actually Does

The setting lives at Tools > Options > Document Properties > Weldments > “Automatically update cut lists” (introduced in 2015). It controls whether SolidWorks regenerates the cut list every time the weldment geometry changes.

Note the distinction between two related settings:

  • “Automatically create cut lists” — on by default in new parts, creates the initial Cut-List1 folder when you add your first structural member
  • “Automatically update cut lists” — controls ongoing regeneration on rebuild

The first creates. The second maintains. Older template files often have update disabled, which creates a different problem: stale cut lists that silently show wrong quantities in drawings until someone manually right-clicks and chooses Update.

When auto-update is enabled and geometry changes, SolidWorks re-runs its consolidation algorithm. It collapses identical members into single folders, splits members that differ, and renumbers everything. Custom properties live in those folders. If a folder gets merged with another, split into two, or renumbered, the properties don’t migrate — they either orphan or attach to whatever folder happens to occupy that position in the new tree.

Consolidation Rules and Why They Matter

SolidWorks merges cut list items only when all of these match:

  1. Structural profile (cross-section geometry)
  2. Total body length
  3. All applied cuts, copes, or holes (must be geometrically identical)
  4. Material (if assigned)
  5. Weld gaps from Trim operations

A single miter trim difference separates two otherwise-identical members into distinct cut list entries. One extra hole on one tube does the same. This means that adding a mounting hole to one member in a family of identical tubes will split that item into a separate folder — and the custom properties you applied to the original folder are now on the wrong item.

This fragility is especially pronounced in multi-config parts where member geometry varies between configurations.

The Delete Bodies Problem

The most common way engineers lose cut list custom properties is through Delete Bodies features used to create configuration-specific weldments.

The problem: SolidWorks weldment cut lists have no concept of configuration-specific body exclusion. The “Exclude from Cut List” option exists but it’s global — it applies across all configurations. If you want member X present in Config A but absent in Config B, the only built-in mechanism is a Delete Bodies feature, and that feature must live at the end of the feature tree to avoid parent-child dependency failures.

When the cut list updates after a Delete Bodies operation, it re-consolidates based on whatever bodies remain. This creates new Cut-List-Item folders, renumbers existing ones, and orphans the custom properties you carefully assigned. The BOM in your drawing inherits whatever is left.

The secondary issue: Delete Bodies features compound. A part with three configurations, each excluding different members, ends up with a stack of Delete Bodies features at the tree bottom, each interacting with the others in ways that are difficult to audit.

The Correct Approach: Feature Suppression

SolidWorks automatically creates two configurations in every weldment part:

  • [As Welded]: Derived configuration with all machining features suppressed
  • [As Machined]: Top-level configuration with post-weld holes, fillets, and chamfers active

The cut list always reads the [As Welded] configuration. It does not care about what happens in [As Machined]. If you add a hole to a tube in [As Machined] and it’s suppressed in [As Welded], the cut list shows the unholed member — as it should, since that’s what arrives at the welding station.

The right architecture for configuration-based weldments is to suppress features, not delete bodies:

[As Welded]:   All structural members present
               All machining features suppressed
               Cut list reads this — never change it

[As Machined]: Add post-weld operations here
               Suppress them when switching to [As Welded]

Config A / Config B:
               Suppress specific structural member features
               (not bodies — the feature that creates the body)
               Cut list rebuilds based on which features are active
               Custom properties stay on stable folders

When you suppress the feature that creates a structural member rather than adding a Delete Bodies feature downstream, the cut list simply shows fewer items. The folder identity doesn’t change for the remaining items, so custom properties survive configuration switches.

The key rule: never suppress the member itself if you can suppress the weldment group feature that contains it. If your structural members are in discrete Weld Groups, suppressing a Weld Group suppresses all its members cleanly, the cut list updates accordingly, and folder identity for unsuppressed items is preserved.

When to Disable Auto-Update

For large weldments — anything above 100 structural members — auto-update imposes a rebuild cost on every geometry change. If you’re iterating on member lengths or cross-sections, that cost adds up.

The workflow for these parts:

  1. Disable auto-update in Document Properties > Weldments
  2. Work through geometry changes without the cut list regenerating
  3. Before entering drawing space or exporting a BOM, manually right-click the Cut List folder > Update
  4. Export

The cost of a manual update is the same as auto-update — you’re just controlling when it happens. For parts where cut list stability is critical (lots of custom properties, complex multi-config structure), manual control is safer regardless of part size.

Document templates matter here. If your company template has auto-update off, every new weldment starts without it. If it’s on, every new part regenerates on rebuild. Audit your template settings and document what the standard is — this is the kind of setting that’s easy to inherit and hard to track when something breaks.

API Access: IBodyFolder and Custom Properties

The SolidWorks API exposes cut list management through IBodyFolder:

// Get the root cut list folder from a part document
IPartDoc swPart = (IPartDoc)swModel;
IBodyFolder swCutListFolder = swPart.FeatureByName("Cut-List1") as IBodyFolder;

// Check if auto-update is enabled
bool autoUpdate = swCutListFolder.GetAutomaticCutList();

// Disable auto-update programmatically
swCutListFolder.SetAutomaticCutList(false);

// Trigger a manual update
swCutListFolder.UpdateCutList();

To read or write custom properties on individual cut list items, you go through IFeature.CustomPropertyManager:

// Get a specific cut list item by name
IFeature swCutListItem = swModel.FeatureByName("Cut-List-Item1");
ICustomPropertyManager swPrpMgr = swCutListItem.CustomPropertyManager;

// Read a property
string val = "";
string resolvedVal = "";
swPrpMgr.Get6("PART_NUMBER", false, out val, out resolvedVal);

// Add or update a property
swPrpMgr.Add3(
    "PART_NUMBER",
    (int)swCustomInfoType_e.swCustomInfoText,
    "ABC-001",
    (int)swCustomPropertyAddOption_e.swCustomPropertyReplaceValue
);

Critical limitation: The API returns properties from the active configuration. If you need to read configuration-specific cut list properties across multiple configs, you must call swModel.ShowConfiguration2("Config A") first — a blocking operation that makes scripted multi-config processing slow. Batch operations on weldments with many configurations should process one config at a time and cache results.

For robust property synchronization across config switches, the documented approach is a MacroFeature with a PostRegenerateListener that fires on OnIdleNotify and copies properties after the cut list finishes recalculating. Direct expression links in custom properties ($prp@CutList-Item1) often fail for legacy parts or complex consolidation scenarios.

The Multi-Config BOM Problem

Cut list properties always come from [As Welded]. If you assign configuration-specific custom properties to [As Machined] — expecting them to appear in drawing BOMs — they won’t. The BOM reads [As Welded] regardless.

The workaround: push properties to the file level instead. Use a design table or configuration-specific file properties to store per-config values. Reference those from the cut list using property links ($prp@"PropertyName"). This keeps the cut list stable and avoids the config-reading issue entirely.

For teams doing automated DXF exports from assemblies with weldments, batch exporting flat patterns from weldments has its own complications — the cut list determines what gets exported and in what quantity. A stale or reorganized cut list produces incorrect file counts. The cut list name survival guide covers how names travel through insert-part and derived configs when you’re managing deeper hierarchies.

If your weldment BOM feeds into a manufacturing BOM, the EBOM vs MBOM gap is where cut list instability tends to surface first — one team sees the [As Welded] properties, another sees file-level properties, and neither matches what’s in ERP.

Summary

The cut list auto-update isn’t broken — it’s doing exactly what it was designed to do: consolidate identical bodies after every change. The problem is that custom properties are stored in the folders that consolidation rebuilds.

The fixes:

  1. Use feature suppression instead of Delete Bodies for configuration-based member exclusion — keeps folder identity stable
  2. Know the [As Welded] rule — cut lists always reflect this configuration, regardless of what [As Machined] contains
  3. Disable auto-update for large weldments and update manually before drawing or BOM work
  4. Store per-config values at the file level, not in cut list item properties, if they need to be config-specific
  5. Use IBodyFolder.SetAutomaticCutList(false) and UpdateCutList() for scripted workflows where you control update timing

The pattern of adding properties to cut list items and then losing them to a rebuild is predictable once you understand the consolidation rules. Avoiding Delete Bodies is the highest-leverage change most teams can make.