Persisted State

By default, data produced during a process run exists only for the lifetime of that run. Once the process completes, that data is gone.

Persisted State fills this gap by giving you a place to store values that need to live longer — across retries, across runs, or even across entirely different processes.

At its core, Persisted State is a simple key–value store managed by Unmeshed, designed specifically for workflow use cases.

---

Each persisted state entry consists of:

• Name (Key): string
• Value:
  • string
  • integer
  • boolean
  • JSON object

This flexibility allows you to store anything from a simple feature flag to a structured payload that multiple processes can consume.

---

Persisted State supports the following operations, each exposed as a step action.

Creates a new persisted state entry.

Use this when you are confident the key does not already exist.

Inputs required:

• Name
• Value

---

Updates the value of an existing persisted state.

Use this when the key is already present and you want to modify its value.

Inputs required:

• Name
• Value

---

Updates the value if the key exists, or creates a new entry if it does not.

This is the recommended option when you are unsure whether the key already exists.

Inputs required:

• Name
• Value

---

Retrieves the value associated with a persisted state key.

Use this when you need to access data stored earlier.

Inputs required:

• Name

---

Removes a persisted state entry permanently.

Use this when the data is no longer required.

Inputs required:

• Name

---

Retrieves multiple persisted state entries in a single operation.

This is useful when several related values need to be fetched together.

Inputs required:

• Names (list of keys)

---

Unmeshed provides a dedicated Persisted State Dashboard where you can view all created persisted states.

From the dashboard, you can:

• See all persisted keys
• Inspect their current values
• Quickly verify what data is being stored and reused across process runs

This is particularly helpful for debugging workflows and understanding shared state across executions.

---

Persisted State is a good fit when:

• Data must survive beyond a single process execution
• Multiple process runs need access to the same value
• You want to avoid recomputing or refetching the same data repeatedly

If the data is only relevant within a single run, regular step outputs are usually sufficient. For anything that needs to live longer, Persisted State is the right tool.