Restore Earlier Changes

Restore a saved state to recover an earlier workflow definition in development. Until you publish again, live triggers and agent tools keep the previous release. Owner Test tools use the restored definition immediately. The agent’s own draft and published version stay unchanged. Restore creates a new state. It cannot undo record writes, provider actions, or whole-workflow deletion.

For Invoice intake, recover a field removed from Check invoice, then test before publishing.

Save a checkpoint you can recognize

In the app: open Workflows → Invoice intake → Dev → Version history. Choose the save icon beside Current version, enter Before invoice schema changes as the Version Name in Save new version, and choose Save. If you’re recovering an existing mistake, save Before recovery first.

With an assistant: list workflows to find Invoice intake’s ID.

cai workflow list --limit 100 --json

Note Invoice intake’s id in data.items as <workflowId>. While data.hasMore is true, absence from this list does not prove a workflow is missing. Obtain missing IDs from the app or owner. The commands below use the pinned workflow and the default development version. For MCP calls, always provide workflowId and omit version.

Pin the workflow, save your checkpoint, and list its history.

cai use <workflowId> --json
cai workflow save --name "Before invoice schema changes" --json
cai workflow history --json

Keep data.headStateId from the save response as the checkpoint ID. MCP uses workflow_state_save with name, then workflow_history.

Choose a state, not a history group

In the app: expand an editing group and select an individual state to preview it.

With an assistant: look in data.history for type: "single" rows with id, or type: "group" rows with groupId. A group ID cannot be restored. Note the relevant <groupId> and expand it to list individual states.

cai workflow history --group <groupId> --json

Use an individual data.history row’s id as <workflowVersionStateId> to inspect that state’s definition.

cai workflow document --state <workflowVersionStateId> --json

MCP uses workflow_document_get with stateId. Check flows, inputs, outputs, schema fields, connection bindings, and triggers before choosing.

You can list and restore states within separate limits. Each cutoff is server-local midnight the stated number of calendar dates before the request. States created exactly at that cutoff are included.

Plan	Listing cutoff	Restore cutoff
Free	None	7 dates ago
Starter / Pro	90 dates ago	90 dates ago
Max / custom	None	None

Restoring a visible state can fail with This workflow version is outside your plan version history limit. It must also exist and belong to the target version.

Recover the development definition

When you restore, the entire development definition is replaced. Later flows, nodes, expressions, triggers, and schemas disappear. Omitted collections become inactive. Their rows remain stored. When schemas return, they expose retained values, including changes made since the checkpoint. Restoring amount cannot change a stored 1500 back to 120.

Saved connection IDs also return. Restore cannot recreate or reauthorize invalid connections. Check restored accounts and destinations before testing. Triggers return to their saved settings for enablement and permission to receive development events. If a source is still attached, its next real event can immediately run development without publication.

In the app: select the state’s restore icon and confirm Restore in Restore previous workflow version? Current version and Live history have no restore icon. If you have unsaved edits, the first saved state remains restorable. Unless permission is intentional, open each restored trigger and turn Allow test events in dev mode Off.

With an assistant: restore the state, then immediately audit triggers to check their permissions.

cai workflow restore --state <workflowVersionStateId> --json
cai trigger audit --json

Check data.restoredFrom in the restore response and retain data.headStateId. MCP uses workflow_state_restore with stateId, then trigger_audit. Inspect data.items[].deployment.allowTestEvents. For each unintended permission, use its triggerId as <triggerId> to turn it off.

cai trigger test-events <triggerId> --disallow --json

MCP uses trigger_test_events_set with triggerId and allowed:false.

If restore fails or times out, inspect status and history before retrying. Schema synchronization can fail after the new state exists. Repeating restore adds another state. Review the current definition’s status, history, and outline, and check its validity.

cai workflow status --json
cai workflow history --json
cai workflow outline --json
cai workflow validate --json

Test the affected path before publishing

In the app: open restored Check invoice in Dev, then choose Test (tooltip: “Test current flow”). The example uses the rule Amount > 1000: expect INV-104 / 120 to return review_needed:false and INV-105 / 1500 to return review_needed:true.

With an assistant: note Check invoice’s id in the restored outline’s data.flows as <flowId>. Use that same value as <nodeIdOrFlowId> to inspect the flow and its inputs.

cai flow get <flowId> --json
cai run inputs <nodeIdOrFlowId> --flow --json

MCP uses run_inputs with nodeIdOrFlowId set to that flow ID and flow:true. Development tests perform real configured writes and provider actions. Verify destinations first. If the labels match, run both fixtures to check their results.

cai run flow <flowId> --target dev --inputs '{"Invoice ID":"INV-104","Amount":120}' --json
cai run flow <flowId> --target dev --inputs '{"Invoice ID":"INV-105","Amount":1500}' --json

Expect INV-104 / 120 to return review_needed:false and INV-105 / 1500 to return review_needed:true.

MCP uses run_flow twice with flowId, target:"dev", and each fixture as a parsed inputs object. For Store invoice, also read development rows. A pure check does not prove storage. Follow Test a Workflow for execution evidence, then Publish a Workflow to make the recovered definition live.