Advertisements

The “New item” menu in modern SharePoint document libraries now allows adding templates

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.…

Advertisements

10 reasons putting team/department documents in SharePoint is better than shared drives: Part 2

Asset 1mazeThis post is a continuation of 10 reasons putting team/department documents in SharePoint is better than shared drives.

See part one for information about:

  1. Version history
  2. Approvals/Administration
  3. Check-in/Check-out
  4. Co-editing
  5. Archiving & retention

And below for information about:

  1. Sharing and security
  2. Remote access
  3. Metadata and views
  4. Workflows & alerts
  5. Sync & export

10 reasons putting team/department documents in SharePoint is better than shared drives: Part 1

Asset 1mazeYou 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:

Part One:

  1. Version history
  2. Approvals/Administration
  3. Check-in/Check-out
  4. Co-editing
  5. Archiving & retention

Part Two:

  1. Sharing and security
  2. Remote access
  3. Metadata and views
  4. Workflows & alerts
  5. Sync & export

Convert SharePoint documents to PDF automatically using Microsoft Flow

convert.PNG

We’ve been waiting a lifetime (dramatic?) for this feature. And now it’s here! Sort of.

Currently, with a new “Preview” action release in Microsoft Flow, we’re able to convert documents to PDF in OneDrive for Business via workflow. While this isn’t ready for SharePoint yet, we can make it look that way for our end users. Basically:

  1. When a file is created or modified in SP
  2. Create document in OneDrive for Business
  3. Convert document
  4. Create document in SP

It’s roundabout but we get exactly the result often requested: convert SharePoint docs to PDF automatically. Here’s how to set this up. A video walkthrough is available at the bottom of this post.

Automating item-level permissions in SharePoint document libraries and lists

workflowitemlevelpermissions

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!

“Edit in Word” (or Excel) not opening document in Office 365, or “Read-Only” status upon opening and trying to save changes

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.