Steel structure repaired component archive inherited sharing checklist

A steel structure repaired component archive inherited sharing checklist helps EPC teams catch a subtle archive problem: the repair file itself may look controlled, but the parent folder, migrated workspace, or copied handover folder still gives broad access to users who should not open final repair records.

Inherited sharing is easy to miss because it is not always visible in the final file name or archive index. It can expose repair photos, NCR closeout evidence, engineering dispositions, owner acceptance notes, and transferred item records through a folder-level setting that was created earlier in the project.

1. Map the full archive path

Start by mapping the complete path from the final archive index to the actual evidence file. Do not review only the file-level permission screen. Inherited sharing normally comes from one or more parent locations.

• Record the final archive index location and the actual file storage location.
• List every parent folder above the repaired component record.
• Identify whether the folder was copied from a temporary review workspace.
• Check whether owner handover folders inherit settings from a broader project folder.
• Record whether the file has unique permissions or inherits from the parent path.

For general archive access review, use the archive access checklist.

2. Identify inherited sharing sources

Inherited sharing can come from several project habits: open review folders, shared photo folders, old transmittal folders, site handover areas, or migrated cloud workspaces. Each source should be reviewed separately.

For migration-specific checks, use the archive link migration checklist.

3. Compare inherited access with the final access matrix

Inherited sharing is acceptable only when it matches the approved final access matrix. If the parent folder grants access to a group that is not listed in the final archive rule, the repaired component record is over-shared.

• Compare inherited users and groups against owner, quality, site, and engineering roles.
• Check whether expired project users still inherit access through a legacy group.
• Check whether broad project groups can open restricted repair dispositions.
• Check whether procurement, logistics, or temporary reviewers still inherit final archive access.
• Record every inherited role that does not match the approved matrix.

For role rules, use the archive access control checklist.

4. Decide whether to break inheritance or move the file

There are two common corrections. The team can break inheritance and assign controlled roles at the folder or file level, or move the record into a controlled final archive folder. Choose the correction that preserves retrieval and avoids creating duplicate records.

For over-broad access correction, use the archive over open access checklist.

5. Retest access after inheritance changes

Changing inheritance can accidentally remove valid owner access or keep an old group active through another path. Retest from practical user positions before closing the correction.

• Test anonymous or anyone-with-link access if open links were previously used.
• Test an expired reviewer or removed project user.
• Test an owner handover user who should open final accepted records.
• Test a quality user who should open NCR and repair evidence.
• Test an engineering reviewer who should open technical dispositions.
• Test a site user who should only open installation-relevant final files.

For user-position testing, use the archive access retest checklist.

6. Update archive indexes and transmittals

After changing inherited sharing, update the references that lead users to the archive. A corrected permission setting can still create confusion if old indexes, transmittals, or comment logs point to folders that no longer open for the right people.

• Update final archive indexes with the controlled file or folder route.
• Record old inherited paths that were retired or restricted.
• Update transmittal references if the file moved to final archive storage.
• Check that broken links were not created during permission correction.
• Attach a short note explaining the access change and final retrieval route.

For broken route checks, use the archive broken link checklist.

7. Record the inherited sharing correction

The correction record should make it clear what was inherited, why it was wrong, what changed, and how retrieval was retested. This protects the archive when future teams question why an old folder no longer opens.

• Record source folder, inherited group, component mark, repair number, and evidence type.
• Record whether the issue came from parent folder access, copied workspace settings, or migration.
• Record the approved final access matrix used for comparison.
• Record whether inheritance was broken, restricted, retained, or replaced by a final archive route.
• Attach retest evidence for denied users and approved users.

For traceability, use the repaired component audit trail checklist.

Final inherited sharing checklist

Before accepting a repaired component archive, confirm:

• The complete archive path and parent folders were mapped.
• Temporary review folders, photo folders, handover folders, and migrated workspaces were checked.
• Inherited users and groups were compared with the final access matrix.
• Over-broad inherited access was corrected without breaking required owner retrieval.
• Anonymous, expired, owner, quality, engineering, and site users were retested.
• Archive indexes and transmittals were updated after permission changes.
• The inherited sharing source, correction, approval, and retest result were logged.

Red flags in inherited sharing

• A repaired component file says restricted, but the parent folder is open to a broad project group.
• Repair photos inherit access from a general photo folder used by many temporary users.
• Engineering dispositions sit under an owner handover folder with mixed audiences.
• Migration copied old review permissions into the final archive workspace.
• Breaking inheritance removed owner access and no retest caught it.
• Old transmittals still point to folders that now fail for approved users.

Buyer note: Inherited sharing should be reviewed before final archive acceptance, not after a retrieval problem occurs. EPC buyers should require folder-path mapping, access matrix comparison, correction evidence, retesting, and an archive update record.