Start with the failed detail
| Cause | Next action |
|---|---|
| Unresolved recipient or missing destination item | Fix the identity/content match and prepare the affected work again. |
| Access denied or sharing policy | Ask the destination administrator to check connector permissions and the relevant tenant/site policy. |
| New guest not ready or invitation rejected | Inspect the guest invitation and directory error; avoid creating another guest without checking for an existing one. |
| Source changed | Use the source safety-check decision and update the batch when required. |
| Provider throttling or temporary service failure | Inspect the run's retry/progress detail. Wait for the current background attempt to finish before starting overlapping work. |
Retry deliberately
- Check that the previous run is no longer actively working.
- Correct the failure's cause. If the approved scope changed, prepare and review a new plan.
- Use the batch's offered retry action for incomplete work when applicable.
- Review the resulting per-site operations and verification again.
- Compare credit usage and exceptions with the first attempt. Already-consumed unique items and already-present access should not be charged again.
What a retry preserves
The restore engine checks existing access and uses recorded item/credit history so repeated work does not intentionally create duplicate grants or consume another credit for the same previously consumed item within its licensed scope.
This does not mean every error can be solved by retrying. A wrong destination, blocked domain, unsupported role, or changed source requires a corrected decision, not repeated execution.
Do not assume a failed run removed previous changes
Successful permission changes remain in Microsoft 365 if a later operation fails. Review actual destination permissions if you need to reverse an incorrect change. Deleting a project or preparation record is not a rollback of destination access.