Hide version history from external users (link sharing)

Occasional Contributor

Hi all,

I would like to hide the version history of our documents in Sharepoint from all external users, no matter how they collaborate on our documents (read and edit / invited through "All" link or specifically, etc.). In other words, I would like to set Sharepoint up so only internal users can ever see version histories. Is that possible? I've been researching and googling like crazy and I can't find anything. Can anybody help?

Thanks a lot,


12 Replies

It is not possible to apply different permissions to document versions. One possible approach might be to use a flow to "move" document versions to a different library where you can use permissions to prevent external users from accessing the items. The "move" needs to be made using a different security context because the external user will not have write permissions in this shadow library.
This also affects your internal users: they need to go to a separate library to access the versions. Search will also return search results from this other library. This is far from ideal.
One more thing: are the external folks allowed to see the changes in the latest document version from the different users? making sure they don't see that may also be tricky.
Summary: this seems like a requirement that is hard to implement

@Paul de Jong 

Hi Paul

Thanks a lot for your answer. I hesitate to duplicate documents - that can only lead to mistakes and confuse my users. I found this solution, but I can't make it work the way I need it to: https://sharepointmaven.com/how-to-prevent-users-from-accessing-old-versions-of-a-document/

To answer your question: yes, the external users should be able to see and edit everything in the latest version. They just shouldn't be able to see older versions.



Moving/copying documents around is bad. Fully agree.

The "CUSTOM PERMISSIONS LEVEL" approach should work.
One thing you should also check is whether the external users connect using OneDrive for Business.
If they use local copies and the sync has not yet run then they will have access to a previous version. Perhaps theoretical but something to be aware of.

@Paul de Jong 

Hi Paul

Thanks a lot for your answer and for the pointer about OneDrive. I'll keep that in mind.

If you don't mind, would you be willing to help me make the custom permissions approach work? What group do I give these custom permissions? Website visitors only have Read rights at the moment. I don't understand how this goes together with the edit rights we give external users when we invite them via link sharing.




Hi @Barbara_EM


Maybe that can help you. In SharePoint, you can create a permission level where you disable the option to view version history, create a group of members of external users, and assign the permission level to that group. I tested it in my environment and it worked! :happyface:

If you want, I'll send you step by step.


A step by step would be super helpful, thanks so much. I've tried the permission level approach but I couldn't make it work.

Thank you!




Where exactly are you having problems?  The second option provided within the SharePoint Maven link is pretty detailed and shouldn't give too many problems.  On a high level you're basically creating a new group (which is a collection of users), then attaching a custom permission group to it.  Once these are done, you'll edit the permissions on the library level and add this custom group there. 


A step by step would (using content from the SharePoint Maven blog) be something like this: -

  1. Navigate to the root (the very top-level site) of the site collection where your site resides
    Gear Icon > Site Settings
  2. Under Users and Permissions choose Site permissions
  3. From the ribbon, choose Permission Levels.  This is a screen that shows you all the existing permission groups.  Note it won't tell you where these are applied
  4. To create a custom permission level, I suggest we just copy an existing one and adjust it slightly. So go ahead and click on Edit Permission Level
  5. DON’T MAKE ANY CHANGES on the screen that appears next. Otherwise, you will mess up the out of the box permission level. Instead, just scroll all the way down and choose Copy Permission Level
  6. Once the Permission Level has been copied, you can now make changes to it. Give it a name, you can also specify in the description the specifics of this custom permission level.  Next, scroll down to a list of specific permissions and un-check both View Versions and Delete Versions
  7. Scroll down to the end of the page and click Create. Now, our custom permission level has been created!
  8. The next step would be to apply this to a SharePoint User Group, either a new one or an existing one.  I'll assume that a new one is the best way for this.  So, using the cog --> Site Settings --> People & Groups to navigate to the People and Groups page.  This should resolve to People and Groups page (.../sites/SITE_NAME/_layouts/15/groups.aspx).  In here look for the New --> New Group action.  This loads a new screen
  9. In this new screen, assign the name and description as required.  Make sure to scroll to the bottom of the page and assign the permission group you created earlier
    1. SPO_User_Group_Permissions.JPG
  10. Once this has saved.  Click on Site Cog --> Site Contents.  This loads a view of all the libraries you have.  Hover over the tile for the library / list you want to amend and look for the ellipsis (...) to the right of the library name.  Click on this and select settings
  11. In this new page, look under the the Permissions and Management header for Permissions for this document library.  This loads a new screen
    1. Permissions for this document libraryPermissions for this document library
  12. If this library has permission inheritance, you'll see the group added here.  If not, you'll need to add the group via the Grant Permissions button.  You'll still need to add the relevant members to this group.

Hope that helps!

Hi@Steven Andrews 

Thanks so much for your answer and for the detailed explanation. My issue is with the members of the new group. They're not set in advance so I can add them to the group individually. It should be <all external users> (i.e. everybody except my team). I can't figure out how to make that happen. We have one group called "Website Visitors". I'm not sure if that's the right one. But this group only has read rights. So I don't know how that goes together with the edit rights we give our external users through link sharing.

I hope I'm explaining my confusion in a way that makes sense...?



@Steven Andrews @alexiaolreis1997 @Paul de Jong 

Can anybody help with my question? I would be super grateful.

Thanks so much and all the best,



Whilst I think that the solutions given will work, these are somewhat scuppered by the fact you'll be granting rights via a very wide mechanism.  


What also doesn't help is that SharePoint rights are additive, which means if a person is given a low permission set (like read) and a higher one (like edit), they'll be granted the maximum rights.


So I suppose you'd be looking at your external users, assuming all they need is read rights, having minimal permissions whilst your own team of editors would have a higher permission set granted via Edit rights.

Hi@Steven Andrews 

Thank you very much for your answer. I think that's basically what I struggle with.

If I give the following rights:

- external users: read, don't see version history

- internal editors: edit, see version history

then what happens if we send an external user an edit link (which we do often)? I'd like them to then have the following rights:

- edit, don't see version history

but I'd assume they would then get:

- edit, see version history (like the internal editors). How do I avoid that?

I did some more research and found out that I would have to edit the permission level "Limited Access" used for link sharing, which is apparently not possible (https://docs.microsoft.com/de-de/sharepoint/sites/user-permissions-and-permission-levels).


@microsoft: Is there a workaround for this? I really don't want external users to be able to see our version history - there might be sensitive data in there.