Remove SharePoint file versions

This automation action deletes older versions of a SharePoint file. You choose how many major and minor versions to keep below the current one, and whether the removed versions move to the recycle bin or are deleted completely.

Before you begin

• Your Rencore role includes the Create Automation or Edit Automation permission. Owner, Admin and Contributor have it. See Rencore roles.
• A version removed with Delete Mode set to “Delete completely” cannot be recovered. A version removed with “Move to recycle bin” can be restored from the site collection recycle bin.

Steps

1. Open the automation in the Automation Builder. See Create a custom automation.
2. Click + in the flow and select the Remove SharePoint file versions action.
3. In SharePoint url, check the URL of the site collection the file is in. It is prefilled from the inventory Site Collections object (e.g. {{File.SiteCollection.Url}}).
4. In List Id, enter the ID of the list or library that holds the file (e.g. {{File.ListId}}).
5. In Item Id, enter the ID of the file (e.g. {{File.ItemId}}).
6. Choose what to delete:
   • Delete all versions: removes every version of the file instead of trimming by the counts below.
   • Delete Major versions and Number of major versions to keep: deletes major versions beyond the number you keep.
   • Delete Minor versions and Number of minor versions to keep: deletes minor versions beyond the number you keep.
7. In Delete Mode, choose Move to recycle bin (recoverable) or Delete completely (permanent).
8. Click Save.

Recommended way to run it

1. Trigger the cleanup on a policy violation (for example, excessive version storage), with a threshold so each run is bounded.
2. Work in batches, highest storage first. Order site collections by storage used, and narrow further by department or owner if needed.
3. Test on around 10 items before running across production. Limit the results in the policy that triggers the automation to do this.
4. Measure success by the drop in site collection storage used, before versus after.

How many versions are kept

The current version is always kept, and it never counts toward your limit. On top of that, the automation keeps the N versions directly below the current one and deletes everything older, so you always end up with N + 1 versions in total. The rule is the same for major and for minor versions.

For example, to keep the current version plus the last 5, set “Number of major versions to keep” to 5. You end up with 6 versions in total.

Reading the version label and file size

In the inventory, each file is a single row. Two fields are easy to misread:

• The version label (for example 100, or 12.3) is the number of the current version. Before any cleanup has run, it is a good indicator of version bloat: if versions have never been trimmed, a label of 100 means about 100 versions are stored. The version number keeps going up even after old versions are deleted. After a cleanup, do not use it to count versions: a file can show 100 while holding only a handful. Check the storage the site uses instead.
• The file size shown is the latest version only, not the sum of all versions, so deleting old versions does not change it.

After the first cleanup, the reliable measure is the drop in site collection storage used, not the version label or the file size.

What you see

After a run, the version label and the latest file size stay the same. The current version is untouched. The reclaimed space shows only as a lower site collection storage used. Measure the effect there, before and after the run.

Run 1: Delete major versions, keep 1

A file with major versions 7.0, 6.0, and 5.0 present. “Delete Minor versions” was off, so minor versions are left untouched.

Before, the file had 6 versions:

After running the automation, 5 versions remain:

The latest major version, 7.0, is kept and not counted. 6.0 also stays because “Number of major versions to keep” was set to 1. 5.0 is deleted. Keeping 1 leaves 2 major versions in total.

Run 2: Delete minor versions, keep 2

A draft file with minor versioning on, holding 7 minor versions from 0.1 to 0.7.

Before, the file had 7 versions:

After running the automation, 3 versions remain:

The latest version, 0.7, is kept and not counted. 0.6 and 0.5 also stay because “Number of minor versions to keep” was set to 2. 0.1 through 0.4 are deleted. Keeping 2 leaves 3 minor versions in total.

A follow-up policy for later cleanups

After the first broad cleanup, keep storage in check with a policy that flags files which have built up many versions again. There is no per-file total version count field yet, so combine two signals you already have:

• The version label band surfaces files that have accumulated many versions. Example filter: version label between 100 and 200, on a site collection with high storage used.
• The storage signal keeps the focus on the site collections that consume the most space.

Point the Remove SharePoint file versions action at that filtered set to trim the high-version files driving storage consumption. Because the label keeps counting up and is never lowered by a cleanup, treat the band as a helpful pointer rather than an exact count. Confirm the result by the drop in site collection storage used.