Cleanup Workflow

MungePoint’s cleanup workflow is built on a confirm-first model. No changes are made to your SharePoint content until you have reviewed the findings, approved specific actions, and explicitly executed them. Every action is logged locally.

The three-phase workflow

Phase 1: Review

After a scan completes, MungePoint presents its findings organized by dimension (duplicates, staleness, naming, metadata, index noise). For each finding, you see:

• What was found: the specific files, folders, or conditions that triggered the finding.
• Why it matters: the impact on Copilot retrieval quality and the estimated score improvement if resolved.
• Recommended action: what MungePoint suggests doing about it (delete, rename, fill metadata, archive, etc.).

You can sort and filter findings by dimension, severity, library, or projected score impact. This review phase is entirely read-only. Nothing changes in SharePoint until you move to the approval phase.

Phase 2: Approve

For each finding, you choose whether to:

• Accept the recommendation: approve the suggested action as-is.
• Modify the action: adjust the recommended action (for example, change a suggested file name, pick a different duplicate to keep, or edit a metadata value).
• Skip: leave the finding unresolved for now. It will appear again on the next scan.

You can approve findings one at a time or select multiple findings and approve them in bulk. Bulk approval is useful when you have large sets of similar findings (for example, dozens of duplicate file groups where the recommended “keep” choice is correct).

Tip

Use the Score Simulator during the approval phase to see how your projected score changes as you approve or skip individual findings. This helps you make informed decisions about which fixes to prioritize in this cleanup cycle.

Phase 3: Execute

After approving a set of findings, click Execute to apply the changes to SharePoint. MungePoint processes approved actions sequentially, calling the Microsoft Graph API for each operation.

During execution:

• Progress is displayed for each action.
• If an individual action fails (due to permissions, file locks, or transient API errors), MungePoint logs the failure and continues with the remaining actions. Failed actions can be retried.
• Every successful action is logged locally.

Caution

Execute requires write permissions. If you have only been scanning with read-only scopes, MungePoint will prompt you to re-authenticate with the additional write scopes. See Permissions and Consent for details.

What is reversible

Understanding which actions are reversible helps you make confident cleanup decisions.

Reversible actions (soft delete)

These actions move content to the SharePoint Recycle Bin rather than permanently deleting it. Items in the Recycle Bin can be restored by a site owner or admin within the standard retention window (93 days by default).

• Duplicate deletion: when MungePoint deletes duplicate files, they go to the site Recycle Bin. The copy you chose to keep remains in place.
• Noise removal: empty folders, zero-byte files, and migration artifacts are moved to the Recycle Bin.

MungePoint itself also provides a Recycle Bin browser that lets you view and restore items across sites.

Non-reversible actions

These actions modify content in place. They cannot be undone through the Recycle Bin.

• File renames: the original file name is replaced. SharePoint version history may retain the previous name depending on library settings, but restoring the old name requires a manual rename or another MungePoint action.
• Metadata fills: metadata field values are written to list items. Reverting requires a manual edit or another MungePoint action.

Note

For non-reversible actions, consider using SharePoint’s built-in version history as a safety net. Libraries with versioning enabled retain previous file states that can be restored if needed.

Action logging

Every executed action is logged locally in MungePoint. The activity panel shows what was done, which items were affected, and whether each action succeeded or failed. Failed actions include error details so you can diagnose permission issues or transient API errors.

Recommended cleanup sequence

While you can address findings in any order, this sequence typically produces the most efficient results:

1. Duplicates first. Removing duplicate files has the largest single impact on Copilot retrieval quality and usually produces the biggest score improvement. It also reduces the number of files that subsequent dimensions need to evaluate.

2. Index noise second. Removing empty folders, zero-byte files, and migration artifacts is low-risk (these items have no business value) and further reduces noise in the content index.

3. Staleness third. Archive or remove content that is clearly outdated. Focus on governed document libraries (policies, procedures, compliance docs) where stale content poses the highest Copilot risk.

4. Naming quality fourth. Rename files with cryptic or misleading names. This improves retrieval precision and is most valuable in libraries with high query traffic.

5. Metadata last. Fill metadata gaps in your highest-traffic libraries. This is typically the most time-intensive dimension to address because metadata values require judgment about the correct tag for each item.

Tip

You do not need to address every finding in a single session. Clean up the highest-impact findings, rescan to confirm the improvement, and then address the next tier. Incremental progress is effective and easier to manage than attempting a complete cleanup in one pass.