Core Docs - Core Concepts - Persisted vs. Non-Persisted Workflows

Rock Version: v20.0
Last Modified: 2026-09-04 2:35 PM

Persisted. That might seem like a strange term if you don't have a technology background. It simply means to write something down so that it can be remembered in the future. Think of it this way - some thoughts you have are relevant only to the task you're currently working on. Sometimes, though, you have a thought that you know you'd better write down because you'll need it for a task you'll complete in the future. Writing the thought down persists the idea for use in the future.

Non-Persisted Workflows

Non-persisted workflows are executed but the attribute values are never written down (or in tech terms never written to the database). They exist only in the computer's temporary storage and go away when done. These types of workflows are great when the entire workflow will be processed immediately and will then be completed.

The check-in workflow is a non-persisted workflow. After the check-in process is complete there is no need to store all of the workflow attributes that helped the system pick the right room for the individual. Many of the entity trigger workflows may turn out to be non-persisted. These workflows will be used to make quick decisions about the nature of an update to the data. Keeping the workflow around won't provide benefits in most cases.

Design Using Persisted Workflows
Even if you're certain that you want a non-persisted workflow, it's wise to build the Workflow Type with the Is Persisted setting turned on at first. This lets you check the logging and see what happened under the hood as it ran. Once you're confident everything is correct, you can switch the Workflow Type's Is Persisted setting back off. That's a design-time setting on the Workflow Type editor, so you're free to switch it in either direction at any time. Switching it off won't undo anything for workflow instances you already ran and saved while testing. Those individual instances stay persisted. Delete them yourself from the workflow list if you don't want to keep them.

Persisted Workflows

Persisted workflows write their state and status down. This allows them to run over long periods of time without forgetting their status. Most workflows that individuals interact with will be persisted (e.g., IT Requests, Facility Requests, HR processes, etc.). This allows the workflow to live for hours, days or even years.

Persisted workflows should also be used when a history of what occurred is important. These types of workflows allow you to go back and see what happened when.

Morphing Persistence

Just because a workflow starts out as a non-persisted workflow doesn't mean it has to stay that way. There is a workflow action called "Workflow Persist" that will change the current workflow to a persisted workflow. This is commonly used with workflow types that start with an entry form.

Picture this - a person comes to the first entry screen of a workflow and then changes their mind and closes the page. What happens? In a persisted workflow the loading of the entry screen started a new workflow that is now stored in the database. In a non-persisted workflow, nothing happens. Because of this, it's common for entry workflows to start as non-persisted and then change to persisted after the first entry screen is completed.

We Know What You’re Thinking
Ok, so you’re probably thinking: can I turn a persisted workflow instance back into a non-persisted one? The simple answer is no. That’s different from the Workflow Type’s Is Persisted setting covered above, which you can flip in either direction at any time. Once an individual workflow instance has actually been persisted, meaning its data has been written to the database, either because Is Persisted was on when the workflow started or because a 'Workflow Persist' action ran mid-workflow, that instance stays persisted. There’s no action that un-persists it. If you want it gone, delete the workflow instance itself using the 'Delete Workflow' action.