Autosaving wizards and form drafts

Author: Kevin Hatchoua | Last edit: February 25, 2025 | Design type: Wizard, Form | Product area: Assisted Installer

How autosave works

Autosave should be event-driven, triggered by:

Field changes (e.g., onBlur, after typing stops for a short delay).
Navigation between steps in a wizard.
Periodic intervals (e.g., every 30 seconds, adjustable based on form complexity).
Explicit save actions (when users manually click "Save Draft" where applicable).

Handling incomplete or invalid entries:

Do not autosave drafts if the form contains critical validation errors (e.g., required fields missing).
Show inline validation messages when an error prevents saving.
Only save a draft if the user has entered data in at least one field.
Do not autosave if users open a form but make no changes.

Persistence:

Visual feedback is crucial to reassure users that changes are being saved.

Use a subtle inline message (e.g., “Changes saved”) near the form title or in the wizard footer.
A PatternFly spinner can be shown briefly while saving.

Consider whether an explicit “Save Draft” button is necessary:

Recommended for long, multi-step wizards where users may want control over saving.

Resuming drafts:

If a user exits mid-process, their progress should be retained, allowing them to resume later.
If drafts are displayed in a table view, add a clear “Draft” status.

Draft management & deletion:

Allow users to delete drafts if they want to start over.
If the user cancels a form or wizard, the draft should not be saved automatically.
Option: Show a modal confirmation:
“You have unsaved changes. Do you want to delete this draft?”
- Options: “Yes” / “Save” / “Cancel”