Operating settings

Your settings decide how Assemblified behaves: which location it falls back to, whether open orders hold stock, whether material requirements are written to Shopify metafields, what a packing slip shows. A connected assistant can read them, explain them, and with write access change them — under the same rules the app’s own Settings page follows.

What it takes

Reading settings needs nothing beyond a connection. Changing one needs write access: either an API key created with read & write scope or a web-chat connection granted read & write when it was linked. See API keys and Connect claude.ai or ChatGPT.

Settings are not part of the Enhanced plan gate. Every store on every plan can read and change them.

Reading and explaining your settings

The assistant can read your settings two ways.

Plain — every setting and its current value. Toggles come back as true or false, the default location as its Shopify location id.
Explained — every setting Assemblified has, not only the ones you have already touched, each with a short name, a one-line summary and a fuller explanation of what it actually does, plus the rules around it: which settings page it lives on, what it depends on, and what gets switched off with it.

The explained form is the one that makes an assistant useful here: ask “why is my virtual stock not moving?” and it can look at the relevant toggles and tell you which one is off, in the same words the app uses.

Ask before you flip

The assistant can also ask what a change would do, without doing it. Two questions, both answered without touching a thing:

“Can I turn this on?” — for every setting you are allowed to change, it gets back whether this store can reach it right now, and if not, the reason in plain words: the parent switch that is off, the app that is not installed, the second location you do not have yet.
“What happens if I do this?” — for a specific set of changes, it gets back one answer per setting: it would apply, it is already that value, it would be switched off as a knock-on of another change, or it would be refused — and what to change first so it would not be.

“Before you change anything — can order reservations even be switched on for my store?”

Two things are worth knowing about the answers.

A refusal here is information, not a failure. Nothing went wrong and nothing was attempted; the assistant simply now knows the answer and can tell you what to do first.
“Cannot be checked” is not “no”. If something the rule depends on could not be looked up — Shopify was briefly unreachable, say — the answer says so rather than guessing. Do not read that as a refusal; ask again.

Changing a setting

The assistant can change up to 50 settings in a single step, and they are written together. You describe the outcome you want; it names the settings it is about to change before it writes them.

Three things it can do while changing them:

Try it first. It can ask for the change as a rehearsal — every check runs, the answer says exactly what would happen, and nothing is written. Useful before a change you are not sure about: “what would happen if I turned multi-location off — and don’t do it yet.”
Clear a setting instead of blanking it. Your default location can be cleared back to “never chosen”, which is not the same as setting it to nothing. After that the store looks the way it did before anyone picked one.
Confirm a change that cannot be undone quietly. Disconnecting Floormode while it still holds stock for you is the one change that needs an explicit go-ahead: the assistant will come back and tell you Floormode still has your stock, and will only proceed once you confirm. Confirming does not hand the stock back — there is no way to reclaim it from this side, so those units stay frozen until Floormode releases them.

What it will not let you do

Three guards apply, and they are the same ones the Settings page enforces. They are not advice the assistant can talk itself out of — they are enforced where the write happens.

Only real settings. A name that is not one of your settings is refused, and nothing at all is written — not even the valid changes that travelled with it.
Dependent settings are switched off with their parent. Turning off multi-location sensitive adjustments also turns off order reservations and location-sensitive dynamic adjustments. Disconnecting Logistified also turns off the two toggles that depend on that connection. Turning off a material-requirements metafield writer also turns off its “hide costs” companion. This happens in the same write, so the assistant may report more settings changed than you asked for — that is the dependency, not a mistake.
The reverse is refused, never guessed at. Switching on a setting whose parent is off — order reservations without multi-location, for instance — is rejected with the reason, and nothing is written. Switch the parent on first, in the same request or a previous one.

There is one case where a change can land only partly, and the assistant will say so rather than round it up or down. A few settings are not just a row in your store: connecting or disconnecting Alertified or Floormode tells that app too, and the location settings tell the other stores in your group. If one of those says no halfway through a batch, the settings already written stay written — the assistant reports which ones landed and which did not, and you can retry the rest. It cannot undo the first half; nor could the Settings page.

When a change takes effect

A settings change applies to work that starts after it. It does not rewrite what already happened: orders already executed keep the behaviour they ran under, and reservations already held are not released by turning reservations off. If you are changing a setting to fix something, ask the assistant what it affects before you assume it repairs history.