Inherited does not mean missing
A folder can grant access that its children inherit. Recreating the same grant separately on every child would change the permission structure. An inherited source entry is therefore normally skipped as an individual child operation.
Standard site Owners, Members, Visitors, and administrator access can be baseline access rather than a file-specific share to recreate. Read the entry's reason and confirm the destination's site or parent access separately.
Unique permissions are a different case
A source child can stop inheriting and have its own access. The destination may need a unique permission scope to represent that state. ShareRestore checks authoritative source inheritance information before planning and applying supported direct grants.
For supported direct Read/Edit restoration, verification checks the intended principal, meaningful role, and inheritance state. A source Read grant should not be silently treated as an Edit grant simply because a parent grants more access.
Review the access level
| Access | What to check |
|---|---|
| Read | The planned direct role allows viewing. Test with the recipient and consider any broader access they already have elsewhere. |
| Edit | The planned role permits edits. Confirm this level is intended before approval. |
| Full control or an unsupported/custom role | Read the review reason. Do not assume it will be downgraded to Edit or reproduced automatically. |
Test effective access as well as the restored grant
A person may also belong to a destination group that independently grants broader access. Restoring one correct permission does not remove every other way that person can access the site.
Use the pilot to test a shared parent, an inherited child, and a unique child. If source permission metadata cannot be read, fix the read failure and prepare again instead of treating the missing information as permission-free content.