Save State (Obsolete)

Audience: Low-code Engineers

Skill Prerequisites: Actions, Forms, Tokens

Saves the form's current data under a key, so it can be loaded again later with Load State. The data can be kept in the server session or referenced from a browser cookie. The same key can be used in other forms to share the data between them.

The actions after it keep running. This action is only available in Forms.

caution

This action is obsolete. Existing forms keep working, but don't use it in new forms. As a suggestion, save the data to your own database table with Run SQL Query, and load it again when the form loads.

Typical Use Cases

• Remember what a user entered in one form and pre-fill another form with it, for example on the next page of a process
• Let a user leave a form and come back to it later in the same browser session
• Keep values between page reloads without saving them to your own table

Don't use it to

• Store data permanently or share it with other users. State is tied to the user's browser. Save the data to your own table instead, for example with Run SQL Query.
• Save the form as a report entry. Use Save Report in the Database (Obsolete).

Related Actions

Action Name	Description
Load State	Loads saved state back into the form.
Clear State	Removes saved state.
Auto Save State	Asks the form to save its data in the browser while the user types.
Save Report in the Database (Obsolete)	Saves the report entry that a Browser Cookies state points to.

Input Parameter Reference

Parameter	Description	Supports Tokens	Default	Required
Key	The name the state is saved under, for example OrderForm. Load State and Clear State must use the same key. Forms that use the same key share and overwrite the same state.	Yes	empty string	Yes
Save Location	Where the state is kept. Server Session keeps a copy of the form's data on the server. Browser Cookies stores the form's report entry key in a cookie. See How form state works.	No	Server Session	No

How form state works

Save State, Load State, Clear State and Auto Save State work together, and all four use the same key.

The key. Tokens in the key are replaced first. Then, if a user is logged in, - and their user ID are added to the end. For example, the key OrderForm becomes OrderForm-42 for user 42. Anonymous users get the key as typed. You don't need to add [User:UserID] yourself.

Server Session. The action stores all of the form's current data in the user's server session under the key. This includes field values and the other values the form holds at that moment. It's the default.

• Session data belongs to the user's browser session. Other users can't load it.
• It's lost when the session ends. By default, that's after about 20 minutes of inactivity, but it depends on the site's configuration.
• If the site has no session support, nothing is saved.

Browser Cookies. The action doesn't copy the values. It writes a cookie named after the key, whose value is the form's report entry key ([_ReportKey]). The cookie doesn't expire. When Load State reads the cookie, it loads that report entry from the database. So the values only come back if the report entry was actually saved:

• Turn on the form's Enable Reports (Obsolete) setting and each field's Save to Report (Obsolete) setting, so the entry is saved after the button's actions. See Forms Settings.
• Or add a Save Report in the Database (Obsolete) action.

Form reports are obsolete since version 1.27, so prefer Server Session for new applications.

Loading and clearing. Load State copies the saved values back into the form's data, by name. Clear State removes the session copy or the cookie. Auto Save State is meant to write a Browser Cookies state while the user types, but in version 1.28 nothing is saved. None of the four actions stops execution.

Considerations

• Where it runs. Save State saves the data as it is when the action runs. Put it in a button's actions to save what the user submitted.
• Logging in changes the key. State saved while anonymous uses the plain key. After the user logs in, the key gets their user ID, so the anonymous state isn't found.
• Choose unique keys. Every form that uses the same key reads and overwrites the same state for that user. Use different keys for unrelated forms.
• Session errors are logged, not shown. If the site stores sessions outside the web server's memory and the data can't be serialized, the error is written to the log and nothing is saved.

Examples

tip

To understand how to use the below examples, please see Running Examples.

1. Save the form's data in the session

This action, in a button's actions, saves the submitted data in the session under the ContactForm key. Another form can load it with Load State and the same key.

{
    "Title": "Save State",
    "ActionType": "SaveState",
    "Description": "Keep the contact details for the next form",
    "Parameters": {
        "Key": "ContactForm",
        "SaveLocation": "Session"
    }
}

2. Save a separate state for each order

This action includes the OrderId token in the key, so each order gets its own state. It only runs when OrderId has a value.

{
    "Title": "Save State",
    "ActionType": "SaveState",
    "Description": "Save the draft for this order",
    "Condition": "[OrderId] != \"\"",
    "Parameters": {
        "Key": "OrderDraft-[OrderId]",
        "SaveLocation": "Session"
    }
}

Revised 09/27/2026