Self-Service Portal

A separate portal lets end users get their own backed-up mail and files back — without filing an IT ticket. Nothing executes until a designated approver signs off, and the path a request takes depends on whether BYOVault can tell whose file it is.

Two paths, depending on ownership

Exchange and OneDrive each have one unambiguous owner per mailbox or drive, so an end user can browse their own content directly and point at the exact item or version they want back.

SharePoint and file servers do not share this ownership model. A library or a shared folder can belong to many people at once, and BYOVault does not hold per-file permission data for either workload today.

Both are still fully covered by self-service, just through a different first step.

Browse-and-pick vs. describe-and-resolve

For Exchange/OneDrive, the end user browses their own mailbox or drive and requests a specific item directly. For SharePoint/file servers, the end user instead describes what they need (workload, where it was, roughly when, why) and a Restore Files Approver searches the tenant’s real backup catalog to find and attach the exact file before anything runs. Either way, an approver must sign off before a restore executes.

Access is strictly scoped per user in both cases — one user cannot browse another user’s mailbox or drive through the portal, and a SharePoint/file-server request is only ever resolved against that same tenant’s own backed-up data.

What an end user can do

Browse their own Exchange mailbox and OneDrive contents directly, including version history.
Submit a restore request for a specific Exchange/OneDrive item or version.
Submit a SharePoint or file-server request by describing it — workload, approximate location, roughly when it existed, and why it’s needed — for an approver to locate.
Track every request they’ve submitted, across all four workloads, in one place.

The approval workflow

Submitting a request never restores anything immediately. A designated Restore Files Approver for that tenant reviews it first.

For Exchange/OneDrive, that’s a straightforward approve/reject on a known item.
For SharePoint/file servers, the approver searches the tenant’s real backup catalog — the same browsing tools an operator uses — to find the exact file or folder that matches the request, then attaches it before approving.

Once approved, the restore is carried out one of two ways depending on workload:

For Exchange, OneDrive, and SharePoint, the request runs through the same restore pipeline an operator would use — the same in-place restore described in In-Place Restore.
For file servers, the request is queued to the on-prem agent for local restoration instead, a different mechanism described in File Servers.

No approver, no self-service

A tenant with no Restore Files Approver configured cannot use self-service restore at all, for any workload — browsing and submitting new requests both require at least one approver to exist for that tenant.

Notifications

Each stage of a request’s lifecycle triggers a notification to the person who requested it, and optionally to the tenant’s own IT contacts. This is the same for both paths above.

Submitted
Approved
Rejected
Completed
Failed

BYOVault operators are never a notification recipient for self-service request activity — this stays inside the client’s own loop. See Notifications & Alerts for every other email a client’s contacts can receive.

PreviousMonitoring & Alert Configuration NextRoles & Approvals