Apply, Save Draft and Publish

There are three stages between typing a value and changing live gameplay. Check which stage you completed before repeating an edit.

1. Apply the open form#

Form changes¹ stay in the open form until you confirm them. The confirmation action may be Add material, Save changes, Apply or Save, depending on the form. Accepting it puts the change into the restaurant's local draft².

For example, a Supply offer dialog changes the open point form first. The point form's Save then applies the point and its offers to the shared draft. Closing a form without confirming can discard what you typed.

2. Save the restaurant draft#

Use Save draft in the restaurant header. The server validates and persists the whole restaurant draft. Wait for the success state before navigating away or assuming the data reached the database.

Saving is not gameplay activation. The existing published configuration³ remains in use. An incomplete draft can be useful to retain work, but publication applies the stricter live-readiness requirements. Resolve fields identified by the actual validation response.

3. Publish the saved setup#

Use Publish after the draft is saved and reviewed. The server validates the live restaurant setup and activates the saved configuration. You publish the whole saved restaurant configuration, including pending changes made on other editor pages.

Do not use Publish as a blind way to clear a warning. Review staff, activation, materials, recipes and placements first. A successful publication updates the appropriate world interactions and access information without requiring a normal resource restart.

Read the header and the row together#

A Published material row can coexist with unsaved staff changes. A Draft row can remain after a successful save. Row status and saving the whole restaurant answer different questions.

What happens to existing kitchen work#

Changes to recipe structure, input/output policies, duration or placement can reset the affected restaurant's temporary kitchen work. Do this between active production sessions. Device batches and parked food are temporary; restarting or resetting the kitchen does not return their ingredients.

Changes to the profile, labels, images, staff, supporting locations, interaction type or blip keep unchanged kitchen work. Staff access changes still take effect. Layout-only graph edits save editor organization without changing gameplay or resetting production. Finished inventory products keep their own persistent metadata and consumption state.

Failed or stale saves#

Read the named field or record in the error. Repair it in the owning form and apply that form before saving again. If another authorized editor changed the restaurant draft, refresh and compare the current revision⁴ instead of repeatedly submitting an old draft.

An unsuccessful save/publication is not evidence that the new configuration became live. Reopen the relevant saved view and inspect the last confirmed state. See Kitchen Problems or Database Errors for the corresponding failure.