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.
If you’ve turned on versioning for a document library and are using both major and minor versions, you could end up with hundreds of minor versions not visible to individuals with view or read-only permissions. Saving major versions of each could take a while individually, but luckily there’s a way to do all of them at once.
Go to site settings
Under “Site Administration” go to “Content and Structure”
Click on the name of the document library you wish you work on
Change “Show: 100” to include all of your documents so you don’t have to do this multiple times. You can also change the view to any one of your views in the document library (or all documents as seen below).
Select the Select All icon () and then under “Actions” select “publish.” A pop-up window will you give you the opportunity to enter a comment as to why these documents are being published, then click “ok.”