Results & troubleshooting

Read restore results and verification counts

Separate successful changes, verified access, already-present access, and entries needing attention.

Quick answer

Use the verification result as evidence of destination access. A successful API operation alone is not the same as a verified permission.

Your next step

Open Verify results for the exact batch you executed and inspect failed or unverified rows before closing the work.

Read the outcomes together

OutcomeWhat it tells you
Succeeded + verifiedThe operation completed and the expected destination access or link was found by verification.
Already presentThe expected access already exists; a duplicate grant is not needed.
Not verified / verification failedThe expected result was not confirmed. Inspect the message, even if the request itself was accepted.
Failed / policy blockedAn operation did not complete as required. Read its exact error and stage.
SkippedNo individual restore operation was applied for that entry. Review its reason rather than counting it as a failure.

Why the numbers are different

A file with three recipients can produce three permission rows. A batch also has counts for sites, items, direct changes, and link changes. Compare like-for-like counts and use the detail table to understand what each total measures.

Credit settlement uses unique destination files/folders with a successful verified change. A failed, skipped, or already-present operation does not consume an additional credit simply because it appeared in the plan.

Confirm the real user experience

  1. Check the exact destination path and identity in the result.
  2. Test representative recipients in their own destination sessions.
  3. Confirm the access level and any unique child permissions, not just whether one file opens.
  4. For a newly invited guest, distinguish the recorded permission from invitation redemption and sign-in-policy checks.
  5. Save exports or an audit package and record exceptions that still need action.

If an operation was accepted but access is unverified

Microsoft can accept a request while a policy, approval requirement, or propagation delay prevents the expected permission from appearing. Read the verification detail and check the destination policy and account before retrying.

A verified permission is useful technical evidence, but it does not establish that every conditional access, browser, or business requirement has been tested. Include recipient acceptance checks in your pilot.

Continue with the next relevant guide.

Need help with your project?

Send the exact error and your project, batch, or run reference so we can investigate.

Get support