Choosing the Parameters You Expose

7 min readUpdated Aug 2026

Decide which of the object's numbers a consumer is allowed to change. Hover the Parameters icon in the column at the top right of the viewport, and click the lock on each row: closed keeps the number private, open sends it to the placement panel. Expose two and it is obvious what the object does; expose fourteen and nobody touches any of them.

Know the split before you start. In the editor you choose the name, the kind and the lock, and nothing else. Minimum, maximum, step and the description a consumer reads are set later, in the store publish wizard, and only for objects you publish there. There is no slider and no bounds field anywhere in this editor.

The export lock

Every parameter row carries a lock. Closed means private, open means exported, and the tooltip describes the click rather than the state: an exported parameter reads Exported — click to keep private, an unexported one Not exported — click to export. Read it as an instruction, not a label.

Only exported parameters reach a placement. Everything else is invisible to whoever uses your object, which is exactly what you want for the twenty intermediate numbers your model needs.

Expose the intent, derive the rest

The habit that separates a good object from an irritating one: export the numbers a consumer decides, and compute everything that follows from them.

A bolt-pocket object is a clean example. The consumer decides one thing, the bolt size. From that, the pocket diameter, the counterbore depth, the wall around it and the clearance all follow by formula. Export BOLT_DIA; make the other four expressions that read it, and keep them private. Now the object cannot be put into an inconsistent state, because there is no way to set the counterbore without setting the bolt.

The opposite pattern exports all five and calls it flexibility. What it actually delivers is five ways to build something that does not fit.

Two rules of thumb follow from that:

If two exported parameters can contradict each other, one of them should have been an expression.
If you cannot write one sentence saying what a parameter changes, it does not belong on the panel. You will have to write that sentence anyway at publish time.

Name exported parameters for the thing they control rather than the number they hold, because the name is what a consumer sees and it is not editable at publish: WALL, BOLT_DIA, PLATE_T survive a change of value, THREE_MM does not. Named Parameters covers the naming rules and the reserved words.

Pick the kind for the decision

The kind is fixed when you create the parameter, so pick it for the shape of the choice rather than the value you happen to have.

Choosing a kind

Kind	Use it when the consumer is	Notes
Number	Setting a dimension, a count or an angle	The only kind arithmetic works on
Boolean	Turning a feature on or off	One switch, one variant
Preset (list)	Picking from a family you defined	Each option can set several other parameters at once
Text	Supplying a label, or a string to compare against	Literal strings only: no expressions

A Preset (list) is the strongest tool on that table, and the most under-used. An option can carry assignments that drive other parameters, so one M3 / M4 / M5 row sets a hole diameter, a head diameter and a counterbore depth together, consistently, every time. The parameters it drives go read-only and show ↳ driven by {name} while the preset holds them.

That gives you a shape worth copying. Export the preset. Keep the three numbers it drives private. The consumer picks a bolt size and cannot get the trio wrong.

Options also carry a description field. Nothing reads it. The placement popover, the file preview panel and the store listing all render the option's name and only the name, and the description is dropped the moment the object is published. So put the information in the name: M3 (5.5 mm nut) is a name a consumer can act on, and there is no second line coming to explain it.

Bounds and descriptions are set at publish

This is the split to keep straight. The smart-object editor has no field for a minimum, a maximum, a step or a description, and no interface anywhere sets a range on a parameter. If you leave the editor thinking you have constrained a value, you have not.

Those live in the wizard at the store publish route, in its Parameters step, which introduces itself as These come from the document itself. Set the range each one can be configured within, and say what it does. For each exported parameter you get:

A Description box, prompted with What this parameter changes, and what a good value looks like.
For numbers only, Min, Max and Step.

The step refuses to complete until every parameter has a real description, and numbers get the refusal A slider needs a minimum and a maximum. if the minimum, maximum or step is missing, if the minimum is not below the maximum, or if the step is not positive.

Take that seriously rather than filling it in to get past the screen. The bounds are what stop a consumer typing 90 into a wall thickness and reporting your object as broken, and the step is what makes the slider land on values you can print. A 0.1 mm step on a clearance is useful; a 0.001 mm step is a slider nobody can aim.

The kind labels differ between the two screens, which is worth expecting: the editor says Boolean and Preset (list), the wizard says Toggle and Choice.

You do not choose the control

The consumer's control follows from the kind, and there is no setting for it. A number becomes a slider when it has both a minimum and a maximum, and a plain numeric field when it does not. A boolean becomes a toggle, and a preset becomes a dropdown.

So bounds are not decoration: giving a number a minimum and a maximum is how it becomes a slider. That is the whole mechanism. If you want the object to feel adjustable rather than typed at, the bounds are where you make it happen.

Presets get their own wizard step, described as Named combinations of values, so people can start from something that already works. A preset needs only a name to count as complete, but the name is what a consumer picks from, so 2×3 with magnets beats Preset 1.

When it goes wrong

A parameter you exported does not appear on the placement. Check the lock: private is the default for every parameter you create, so building an entire object and exporting nothing happens more often than you would expect.

A consumer's value produces broken geometry. An out-of-range value is a soft warning inside the editor and never a block, and there is no range at all until you publish with one. If a value must not be exceeded, enforce it in the model with an expression rather than hoping.

A value will not accept typing. A preset is holding it. That row is driven, and the preset has to change or release it.

A parameter is amber with expression references an unknown parameter. Something it names was renamed or deleted, and the row is showing the last value that worked. Renaming never rewrites the formulas that mention the old name, so fix them by hand.

Deleting a parameter something uses. The confirmation says '{name}' is used in {count} input(s). Delete anyway? Inputs revert to literal values. and that is exactly what happens: those fields keep their current number as a plain number, nothing goes red, and the object quietly stops being parametric in that spot.