Note: Applies to SharePoint Online/O365 and modern experiences only.
In SharePoint Server/on-prem, we have to manage content types and allow links to documents before we can link to documents outside the current document library. But in SharePoint Online/O365, there’s a Link option on the New menu that does all the work for us, and without even needing to adjust the library’s content type settings.
Modern experience in SharePoint Online/O365
In a modern-view document library, simply use New > Link.
Then paste a URL to the file, or select it from recent files which, yes, will include files modified even outside the current library.
This will add a link/shortcut within your document library to the document stored/managed elsewhere.
Today I ran across an issue where someone had created links within a classic document library that redirected users to documents stored in a different library. This is easy to do, but for some reason those links were now leading users to blank .aspx pages instead of the intended document.
Note that users weren’t taken to an “invalid” or “can’t be found” error page, but a completely blank page with a URL ending in .aspx. If you’re being redirected to anything other than a blank page the following solution probably won’t apply to you.
I figured out that, somehow, the library in question no longer had the “Link to a document” content type included. You normally can’t delete a content type that is in use, but with the right permissions and perhaps a migration tool or script, anything is possible. Without the content type on the library, the links that once worked under that content type now could not.
Important: The links are not necessarily broken – do not delete them. Once the content type is added again, they should work unless the original URLs have actually changed.
To re-add the link/shortcut content type to the library, follow these directions (same as if you were adding it for the first time):
1. Go to Library > Library Settings
2. Choose Advanced settings
3. Set Allow management of content types to Yes.
4. Click OK to save changes.
5. Under Content Types choose Add from existing site content types
I happily stumbled across an update to modern document libraries I hadn’t noticed before. The modern document library “new item” menu now includes an option to “Edit New Menu” which pulls up this pane in-context:
And also includes the ability to upload a new template directly from the menu, rather than through content type settings.
Any new templates added via this method will use the default content type for that library, but provides a way to have multiple templates for a single content type.
You know that one file, right? The one named “Agenda.docx” in the folder called “November” in the “2008” folder in another folder called “DO NOT Delete” in the “Archive” folder of the “Retired Committees” folder?
Me either. And chances are you don’t need it anymore. But managing team/department documents on traditional shared drives has challenges like this all the time, with management, retention, content ownership, etc. SharePoint, however, can greatly assist in keeping your content current, relevant and organized.
Of course making the switch from shared, common network drives to SharePoint can be intimidating. But the benefits of doing so are well worth the effort to make your team work more efficiently. This post will highlight 10 features in SharePoint you can’t necessarily get from shared network drives:
Edited Dec 10, 2018 to include “for a selected item” function in modern sites.
Can you convert SharePoint documents to PDF without leaving SharePoint? Heck, yeah!
Basically we’ll create this flow:
“When a file is created or modified” in SP -OR- “For a selected item”
Create document in OneDrive for Business -OR- OneDrive
Convert document (OneDrive action in Flow)
Create document in SP
It’s a bit of a hack but we get exactly the result often requested: convert SharePoint docs to PDF automatically. Here’s how to set this up. A video walkthrough using the “created/modified” trigger is available at the bottom of this post.
Item-level permissions come in handy for a number of situations. Here are some examples and food for thought:
Travel plans are submitted to a list, but only those in people columns (supervisor, director, traveler) are allowed to see or find the plan by search.
Allow “content owners” to edit documents, and everyone else to view only.
Allow non-admin individuals to set editing permissions for documents or list items by populating a people column
Using a SharePoint Designer 2010 Workflow and an impersonation step, we can:
Add list item permissions
Inherit list item parent permissions
Remove list item permissions
Replace list item permissions
This tutorial will use the “replace list item permissions” action. Whenever you’re replacing permissions, you must remember to INCLUDE YOURSELF or admin individuals in the replacement permissions or you won’t be able to access the content or help with troubleshooting. Let’s begin!
The people column’s settings are multiple selection, people AND groups as can be seen here. This is absolutely fine (multiple selection, mixing of permission groups with individuals). You may just note the warning in red in the screenshot below:
“Earlier versions of client programs might not support a Person or Group field that allows multiple selections. Adding this field might block those programs from saving documents to this library.”
In your workflow, just make sure you’re returning your people column “As String” and not any of the semi-colon delimited options. That’s all there is to it. Publish the revision and run the workflow again (and you may need/wish to go in and end any workflows that errored out but are still “running”). Best of luck!
When working in Office 365 or SharePoint and you open a document for editing, you get two choices. Edit in Word (or Excel) or Edit in Browser. Editing in browser is typically a safe route but it doesn’t give you full functionality like the clients will.
The issue I’m discussing here is when a user tries to edit a document from SharePoint using the client (not Edit in Browser) the client opens to a blank, gray background (no document) or doesn’t open at all. This is likely an account conflict in syncing or accessing.
In other cases, the document may open, but as read-only. If that’s the case, it’s likely permissions-related. You might first check the user’s specific permissions in SharePoint. Sometimes because of broken (not inherited) permissions, or partial access to a site, users are able to edit in browser, but not in the client. If this is your situation, it could well be the cause.
Hopefully this is a simple fix for you, but as it’s become clear to me a number of times with this issue it can be quite complicated. I have a couple fixes, though the second is less ideal. If anyone else has run into this and would like to offer their experience, please do so in the comments.