Request Lifecycle
A self-service request moves through a clear set of stages, and every transition between them is driven by a specific action — an end user submitting, an approver deciding, or the restore itself reporting back. This page walks through those stages in order, for both request types.
Two request types, two sets of stages
As described in the Self-Service Portal overview, Exchange/OneDrive requests and SharePoint/file-server requests are handled differently because only the first pair has an unambiguous single owner per item.
This split runs all the way through: the two request types are tracked separately, each with its own set of possible stages.
- An Exchange or OneDrive request is created against a known, already-identified backed-up item the end user found by browsing their own mailbox or drive.
- A SharePoint or file-server request is created from a written description only — workload, approximate location, roughly when, and why — with no item attached yet.
Both request types share the same shape of outcomes — Approved, Rejected, In Progress, Completed, Failed — but differ in their starting stage, and in what has to happen before a request can even be approved.
The full list of stages lives in Job & Request States; this page focuses on the transitions between them.
Exchange and OneDrive: submit, approve, execute
| Status | What causes the transition into it |
|---|---|
| Pending Approval | The end user submits a request against a specific backed-up item. A duplicate request for the same item and the same requester is blocked while an earlier one is still Pending Approval, Approved, or In Progress — a rejected, completed, or failed request does not block a fresh one. |
| Approved / In Progress | A Restore Files Approver clicks Approve. The restore starts immediately as part of the same action, recording who approved it and when. The identical execution path an operator’s own manual restore uses is used here too, so there is no separate “start the restore” step. |
| Rejected | The approver clicks Reject instead, optionally with a reason. No restore is ever started for a rejected request. |
| Completed / Failed | Set asynchronously, once the underlying restore actually finishes — not by the approval step itself. The request’s record is updated to match once the restore reaches a final outcome, and the completion time shown is distinct from the time the approver acted. |
If the underlying archived item disappears between submission and approval, approval itself fails: the request moves directly to Failed at the approve step, with no In Progress stage in between.
SharePoint and file server: submit, resolve, execute
A SharePoint or file-server request starts with no known item, so it needs one additional step before it can reach the same shape as the Exchange/OneDrive path.
| Status | What causes the transition into it |
|---|---|
| Pending Review | The end user submits a description of what they need. No item is attached at this point. |
| In Progress | An approver searches the tenant’s real backup catalog, using their own operator-level browse access, and attaches the matching item via the resolve action. Resolving a request approves and executes it in one step:
There is no separate plain Approved resting stage here either. |
| Rejected | The approver declines instead — no match was found, or the request should not be honored — optionally with a reason. No restore is started. |
| Completed / Failed |
|
Notifications follow status changes, with one exception
Four of the five real transitions each fire a notification to the requester, and optionally to the tenant’s configured IT contacts:
- Submission
- Approval
- Rejection
- The final completed-or-failed outcome
The move into In Progress itself does not send its own notification — the “approved” email is sent once the restore has actually been started.
The “completed”/“failed” email is sent later, only once the restore reports back. See Notifications & Alerts for the full set of client-facing emails BYOVault sends.
Because Completed and Failed are only ever set once the restore reports back, a request will show In Progress for as long as its underlying restore or agent poll takes.
There is no separate timeout status distinct from a genuine restore failure — a request that never receives a final update from its restore remains at In Progress indefinitely.