Workflow Template

Backup and Restore Request Workflow

Handles employee requests to restore backed-up data. Captures the request, has IT verify authorisation and backup availability, decides whether to proceed directly or hold for data owner sign-off (when the restore would overwrite current data), performs the restore, has the requester validate the outcome, and closes the request with a notification.

When an employee needs backed-up data restored, requests often bounce between emails and tickets with no clear record of who authorised the overwrite risk or whether IT actually verified the backup exists. This workflow captures the request, routes it through IT verification and conditional data owner approval only when current data would be overwritten, then tracks the restore through requester validation and closure. Teams get a single auditable trail from request to confirmed outcome, reducing back-and-forth and helping restores get completed with fewer disputes over data loss.

Business Outcomes

Reduces time spent tracking down approval status across email threads
Helps prevent unauthorised or unverified restores from proceeding
Supports faster turnaround by routing only overwrite-risk cases to data owner sign-off
Improves accountability with a documented trail of verification, approval, and validation
Helps reduce unresolved restore issues by flagging validation failures for IT follow-up

Workflow Steps

Steps

1
Create Restore Request Recordcreate record
Registers the incoming restore request.
2
Set Status to Receivedupdate record
Marks the request as received.
3
Verify Authorisation & Backup Availabilitycreate task
IT verifies the requester is authorised and confirms a suitable backup exists, then records a proceed/hold decision.
4
Set Status to Under Reviewupdate record
Marks the record as under IT review with the recorded decision.
5
Route on IT Review Decision
Branches based on whether IT decided to proceed directly or hold for data owner sign-off.
review_decision: "Proceed"→Set Status to Approved to Proceed
review_decision: "Hold - Requires Data Owner Sign-off"→Set Status to On Hold
Default→End
6
Set Status to On Holdupdate record
Marks the record as on hold pending data owner sign-off.
7
Request Data Owner Approvalrequest approval
Because the restore would overwrite current data, the data owner must sign off before proceeding.
8
Route on Data Owner Approval Outcome
Proceeds to restore if approved, otherwise denies the request permanently.
approval_status: "approved"→Set Status to Approved to Proceed
approval_status: "rejected"→Set Status to Denied
Default→End
9
Set Status to Deniedupdate record
Marks the request as denied due to lack of data owner sign-off.
10
Notify Requester of Denialsend email
Informs the requester that the restore was denied because the data owner did not approve overwriting current data.
11
Set Status to Approved to Proceedupdate record
Marks the record as approved to proceed with the restore.
12
Perform the Restorecreate task
IT performs the actual data/system restore from the confirmed backup.
13
Set Status to Awaiting Validationupdate record
Marks the record as restored and awaiting requester validation.
14
Request Requester Validationrequest external input
Asks the requester to validate that the restored data/system is correct.
15
Record Validation Resultupdate record
Persists the requester's validation result to the record.
16
Route on Requester Validation Result
Closes the request if confirmed, or routes to IT follow-up if issues were found.
validation_result: "Confirmed - Data Restored Correctly"→Set Status to Completed
validation_result: "Issues Found"→Flag Issues for IT Follow-up
Default→End
17
Flag Issues for IT Follow-upcreate task
Creates a follow-up task for IT since the requester reported issues with the restore.
18
Set Status to Completedupdate record
Marks the request as completed once the requester has confirmed the restore.
19
Notify Requester of Outcomesend email
Notifies the requester that their restore request has been closed.
20
Set Status to Restoringupdate record
Marks the record as actively being restored before IT performs the restore.

Fields

Requester Name*
Requester Email*
System or Data to Restore*
Requested Restore Point (date/time or backup label)*
Business Reason for Restore*
Restore Status*
+7 more fields

Forms

Backup Restore Request

5 fields

Data Views

All Restore Requests

requester_name, system_or_data, restore_point, restore_status +2 more

Dashboard Widgets

Restore Requests OverviewReview Decisions BreakdownRestore Request Pipeline

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 security incident response data breach response

Similar Categories

information technology cybersecurity privacy

FAQs

What happens if the restore would overwrite current data?

The workflow routes the request to the data owner for explicit approval before the restore proceeds. Only requests where the restore is confirmed safe to run directly skip this step. This conditional routing helps prevent accidental data loss without slowing down low-risk requests.

Can this handle requests where IT can't verify the backup is available?

Yes. The IT review decision step lets IT route the request to denial with a notification to the requester if the backup can't be verified or authorisation fails. The status updates automatically so the requester isn't left waiting without an answer.

What if the data owner denies the restore approval?

The workflow routes the outcome to a denial path, sets the status to Denied, and triggers a notification to the requester explaining the outcome. This keeps the decision documented and avoids the request sitting in limbo.

What happens if the requester finds an issue during validation?

The requester's validation result routes the request to a follow-up path where issues are flagged for IT rather than closing the request prematurely. This ensures problems get addressed before the request is marked Completed.

Can we customise who needs to approve at each step?

Yes. Roles for IT review, data owner approval, and requester validation are all configurable directly in assess.one, so you can assign specific people, teams, or approval groups per step. You can also adjust notification triggers and approval logic without any coding.

Who needs access to this workflow?

Typically the requesting employee, an IT reviewer, and — for overwrite scenarios — a designated data owner all need access. Access and permissions for each role are managed within assess.one, so you control who can view, act on, or approve each stage.

How long does it take to get this workflow live?

Publishing the template takes minutes, not weeks. Once published, your team can start submitting and processing restore requests immediately inside assess.one.

What if a request needs additional approval steps beyond data owner sign-off?

You can add extra approval or review steps directly in the workflow builder to match your organisation's specific compliance or sign-off requirements. Step order, roles, and routing logic are all adjustable without external development work.

Does this workflow support audit or compliance tracking?

The workflow records status changes, approval decisions, and validation outcomes at each stage, creating a traceable history of the request. This can help support internal audits or compliance reviews around data handling and restore authorisation.

What if the requester never responds to validate the restore?

Since the validation step and status are configured in assess.one, you can add reminder notifications or escalation logic to prompt the requester or notify a backup approver. This helps prevent requests from stalling indefinitely at the validation stage.

Ready to use this workflow?

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