Before editing a design-table part, decide which value wins

Sun, 08 Nov 2026 · 6 min read · Written with an AI assistant

On a SOLIDWORKS part driven by a design table, a dimension edit can be written back to the table, blocked, or left out of step with an outside Excel file. Know which value is in charge before you change one.

You open a configured bracket, double-click a dimension, type a new value and rebuild. The model looks right, but on a design-table part the model may not own that number: a spreadsheet inside the file might, and your edit can be copied into it, refused, or left out of step with an Excel file someone else treats as the master.

Each of those outcomes is a traceability problem for a change request. Before anyone edits the part, whether an engineer, a macro or an AI agent, someone has to know which value is in charge.

A note on versions: the SOLIDWORKS help pages cited here range from 2012 to 2023. Behaviour and menu names move between releases, so check each point against the help for the version you run.

A dimension with a hidden owner

A design table builds multiple configurations of a part or assembly from parameters in an Excel worksheet embedded in the model (SOLIDWORKS help: Design Table Configurations). Each row is a configuration. Each column is a parameter.

The columns can own far more than dimensions. In a part, a table can control dimensions, feature suppression state, equations, sketch relations, materials and custom properties; in an assembly, it can control component suppression, whether a component is fixed or floating, and assembly feature dimensions and suppression (GoEngineer). So changing the material or a description field in the model can also collide with a table.

Tables are also easy to create by accident. The Auto-create option in the Design Table PropertyManager inserts one automatically (SOLIDWORKS help: Inserting a Design Table Automatically). That is one reason a table can turn up in a part whose current owner never built it.

The cells need not hold plain numbers either. You can use Excel equations and formatting in a design table, as long as the correct data stays in the correct place in the layout (Hawk Ridge Systems). A model edit that touches a computed parameter raises an obvious question: what is in that cell now?

Read Edit Control before you change anything

The Design Table PropertyManager has an Edit Control setting with two options (SOLIDWORKS help: Design Table PropertyManager):

Allow model edits to update the design table. Change a dimension in the model and the new value is written back to the table.
Block model edits that would update the design table. The edit is refused; the table stays as it was.

For a released, change-controlled part, I would set Block. The table is the record of every configuration’s values. With Allow, a quick fix made with one configuration active becomes table content without anyone looking at the row and column it landed in. With Block, the change has to go through the table, where a reviewer can see exactly which cell moved.

Allow has its place in concept work, where the model is where you think and the table follows. The risk with Block is human: an engineer hits a refusal, flips the setting to Allow to get the job done, and never flips it back. If that happens, the change of setting belongs in the change record too.

Embedded copy, linked file: two sources of truth

By default the table is saved in the model document and is not linked to the original Excel file. Changes made in the model do not show up in that original file, though you can link the two (SOLIDWORKS help: Design Table Configurations). A SOLIDWORKS reseller describes the same behaviour: design tables are embedded in the document, not linked (Javelin).

The trap is familiar. A team keeps product-family.xlsx on a shared drive and calls it the master. The part holds a copy. After one change they diverge, and nothing warns anyone.

The alternative is to build the table as a separate Excel file and insert it. If you update a linked table in Excel and then open the model, you can choose to update the model from the table, or the table from the model (SOLIDWORKS help: Inserting an External File as a Design Table). That help page places the update options under the Tools menu; check the exact path in your version.

That prompt is the “which value wins” question asked out loud. It deserves a deliberate answer and a line in the change record, not a reflexive click.

Worked example: one hole spacing, three configurations

Take a hypothetical bracket with three configurations. The embedded table looks like this:

            D1@Sketch2   D3@Boss-Extrude1   $PARTNUMBER
BRK-100-A   40           =B3+30             BRK-100-A
BRK-100-B   60           =B4+30
BRK-100-C   80           =B5+30             BRK-100-C

D1@Sketch2 is the hole spacing. The overall length is a formula: spacing plus 30 mm of edge margin. The help says tables must be formatted properly, and that parameter names in header cells are not case-sensitive (SOLIDWORKS help: Summary of Design Table Parameters).

A change request asks for the B spacing to go from 60 to 65. An engineer activates BRK-100-B and edits the dimension.

With Allow, 65 is written back to the B row. Open the table and check that the length cell still holds =B4+30 and now reads 95, rather than assuming it does.
With Block, the edit is refused. The engineer changes the cell in the table instead, and the formula carries the length.
Either way, if product-family.xlsx on the server is the team’s master, it still says 60.

Note the blank $PARTNUMBER cell for B. $PARTNUMBER accepts any text string, and a blank cell defaults to the configuration name; the same page lists $SHOW as obsolete (SOLIDWORKS help 2012: Summary of Design Table Parameters). Here that is harmless because the configuration name matches the numbering scheme. Rename the configuration during the change and the part number moves with it, which can then appear wherever that part number is reported.

A post-change checklist for any design-table part:

Confirm which configurations the table drives and which columns it owns.
Read the Edit Control setting and record it.
Check blank cells and what they default to, starting with $PARTNUMBER.
Check that Excel formulas are still formulas and still sit in the right cells.
Check suppression states and custom properties across every row, not only the active configuration.
If a linked file or an outside master exists, record which value was kept, model or table, and why.

What this means for CAD tooling

Any script, macro or AI agent that proposes a dimension change should first report whether a design table controls that parameter. Something of this shape would do:

Parameter:       D1@Sketch2 (hole spacing)
Controlled by:   embedded design table
Rows affected:   BRK-100-B only
Edit Control:    Block model edits
Dependent cells: D3@Boss-Extrude1 (formula)
External master: none linked
Decision needed: edit the table cell, or change Edit Control?

Then it should stop and leave the model-or-table decision to the engineer. A tool that quietly flips Edit Control, or picks “update table from model” because it is the default, has made an engineering decision nobody approved.

This is the line we are taking with AI-CAD, our engineering copilot for SOLIDWORKS, which is a prototype under active development: agents plan a change, SOLIDWORKS builds it, and an engineer approves every decision. Design tables are a useful test of that principle, because which value wins is a question about intent, not a software setting.

A design table is a sound way to manage a part family. It just means a dimension has two possible owners, and a change is only traceable when someone has said which one was in charge. If this was useful, follow the journal or get in touch with the parts that have caught you out.