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:
- When a file is created or modified in SP
- Create document in OneDrive for Business
- Convert document
- 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.
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!
This post covers one solution in which a 2010 SharePoint Designer workflow errors out due to invalid e-mail addresses.
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.
When using major and minor versioning, you could run into a situation where you wish to create major versions of all documents so that all are published and visible to all permission levels.