Workflow Template

Backup and Restore Request Workflow

Handles IT data restore requests end-to-end: intake, authorisation/backup verification, optional data owner sign-off, restore execution, requester validation with a bounded retry loop, and closure.

When a restore request lands in someone's inbox, IT teams end up chasing down authorisation, hunting for the right backup, and manually pinging requesters to check the data actually looks right. The Backup and Restore Request Workflow captures every request as a record with its own reference number, walks it through authorisation and backup verification, routes to a data owner for sign-off when the restore could overwrite current data, and loops back automatically if the requester finds a problem after the restore. The result is a tracked, repeatable process where every decision, note, and status change is visible in the record's timeline instead of scattered across email threads.

Business Outcomes

Reduces time spent tracking down authorisation and backup details for each restore request
Cuts back-and-forth emails by routing sign-off and validation directly to the right people
Makes restore status visible at a glance across all in-flight requests
Helps catch bad restores early with a built-in requester validation and retry step
Shortens closure time by automating status updates and notifications end to end

Workflow Steps

Steps

1
Create Restore Request Recordcreate record
Registers the submitted restore request as a record.
2
Set Status to Submittedupdate record
Marks the request as Submitted on the record.
3
Email Acknowledgementsend email
Sends the requester an acknowledgement email with their reference number.
4
IT: Verify Authorisation & Backupcreate task
IT verifies the requester's authorisation, confirms a suitable backup exists, and records their decision.
5
Save Verification Resultupdate record
Persists the backup to use and verification notes to the record.
6
Route on Verification Decision
Routes based on whether IT can proceed, needs sign-off, or cannot restore.
verification_decision: "Cannot restore"→Set Status to Cannot Restore
verification_decision: "Needs data owner sign-off"→Set Status to Awaiting Sign-off
verification_decision: "Proceed"→Set Status to Restoring
Default→End
7
Set Status to Cannot Restoreupdate record
Marks the record as Cannot Restore.
8
Email Requester - Cannot Restoresend email
Notifies the requester that the restore cannot proceed, including IT's notes.
9
Set Status to Awaiting Sign-offupdate record
Marks the record as Awaiting Sign-off.
10
Data Owner: Approve or Reject Restorerequest approval
Requests the data owner's approval to proceed with the restore.
11
Route on Data Owner Decision
Routes based on whether the data owner approved or rejected the restore.
approval_status: "approved"→Set Status to Restoring
approval_status: "rejected"→Set Status to Rejected
Default→End
12
Set Status to Rejectedupdate record
Marks the record as Rejected.
13
Email Requester - Rejectedsend email
Notifies the requester that the data owner did not approve the restore.
14
Set Status to Restoringupdate record
Marks the record as Restoring.
15
IT: Perform Restorecreate task
IT performs the restore using the confirmed backup and records the date restored and notes.
16
Save Restore Resultupdate record
Persists the date restored and restore notes to the record.
17
Set Status to Validatingupdate record
Marks the record as Validating.
18
Request Requester Validationrequest external input
Emails the requester a form asking whether the restored data is correct, and waits for their reply.
19
Save Validation Resultupdate record
Persists the requester's validation comments to the record.
20
Route on Validation Result
Routes based on whether the requester confirmed the restore or found a problem.
validation_result: "Confirmed"→Set Status to Completed
validation_result: "Problem found"→Loop Back to Restore
Default→End
21
Loop Back to Restorerestart from step
Restarts the restore process because the requester found a problem with the restored data, up to 2 times.
22
Set Status to Completedupdate record
Marks the record as Completed.
23
Email Requester - Request Closedsend email
Notifies the requester that the restore request is complete and closed.

Fields

Show all 14 fields

FormData Restore Request

Requester Name*· Text
Requester Email*· Email
System or Data to Restore*· Text
Restore Point (date/time)*· Date
Business Reason*· Long text
Could the restore overwrite current data?*· Choice

TaskIT: Verify Authorisation & Backup

Backup to Use· Text
Verification Notes· Long text
Verification Decision*· Choice

TaskIT: Perform Restore

Date Restored*· Date
Restore Notes· Long text

Other fields

Restore Status· Choice
Validation Result*· Choice
Validation Comments· Long text

Requester Name*
Requester Email*
System or Data to Restore*
Restore Point (date/time)*
Business Reason*
Could the restore overwrite current data?*

Forms

Data Restore Request

6 fields

Data Views

Restore Requests

system_or_data, restore_point, backup_to_use, restore_status

Dashboard Widgets

Restores by Restore Status

Recommended integrations

Setup the following integrations to extend workflow capability.

Send email in the workflow
AWS SES

backup restore requestdata restorebackup recoveryfile restoreIT service

Similar Workflows

IT Service Request Workflow Security Incident Response Workflow Data Breach Response Workflow

Similar Categories

Information Technology Cybersecurity & Privacy

FAQs

What happens if IT decides the restore cannot proceed?

The record status is set to Cannot Restore and the requester receives an email explaining the outcome, including IT's notes from the verification step. The request closes at this point without moving on to sign-off or restore execution, and the reasoning stays visible in the record's timeline.

What happens if the data owner rejects the restore?

The record status is set to Rejected and the requester is emailed to let them know the data owner did not approve proceeding. The request ends there, and the decision is recorded on the record for later reference.

Can this handle restores that don't need data owner sign-off?

Yes. If IT's verification decision is Proceed rather than Needs data owner sign-off, the workflow skips the sign-off step entirely and moves straight to setting the status to Restoring. Sign-off is only requested when the restore could overwrite current data and IT flags it as needed.

What if the requester finds a problem with the restored data?

The requester's validation form response is saved to the record, and if they report a problem, the workflow loops back to the restore step automatically, up to two times. This gives IT a chance to correct the restore before the request moves to Completed, without the requester needing to submit a new request.

What happens after two failed validation attempts?

The loop back to restore is bounded at two retries, so the record's timeline will show each restore and validation attempt in sequence. Staff reviewing the record can see the Restore Notes and Comments from each pass and decide on next steps outside the automated loop if a problem persists.

Who is involved in processing a restore request?

IT verifies authorisation and confirms a suitable backup, then later performs the restore itself, recording notes and decisions at each task. A data owner is brought in only when the restore could overwrite current data, and the requester is kept informed by email and asked to validate the result before closure.

Can we customise the request form or the workflow steps?

Yes. The request form fields and each step can be adjusted by describing the change in plain English or by editing steps directly in the workflow editor, and earlier versions are kept. This makes it straightforward to add extra questions or change routing rules as your restore process evolves.

Does the requester need an account to submit a request or respond to forms?

No account is needed. Requesters submit through the public request form and respond to the validation form sent to their email, with no login required at any point.

How is the status of a restore request tracked?

Each request is a record with a reference number, a status such as Submitted, Restoring, Validating, or Completed, and a full timeline of what happened. Table views and dashboards let staff see requests grouped by status at any point in the process.

What gets recorded during backup verification and restore execution?

During verification, IT's Backup to Use, Notes, and Decision are saved to the record because the workflow waits on that task. During restore execution, the Date Restored and Restore Notes are likewise saved, giving a clear record of what backup was used and when the restore happened.

Ready to use this workflow?

Create a free account and customise this workflow for your business.