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.
If you’re using a document Name field in a workflow but it’s not working as expected, it could be because there are apostrophes (‘) or ampersands (&) in document names. In this case, SharePoint evaluates apostrophes (‘) to ' and ampersands (&) to & As you can see here, most other punctuation evaluates perfectly well:
Note: This problem only occurs when using apostrophes and ampersands in document names, in document libraries. And we can fix the issue without needing to rename the files.
Document names cannot contain these punctuation marks: \ / . : * # “
Regular lists and document library fields aside from the Name field shouldn’t experience this issue. But if you’re using & or ‘ in your file names, and calling those file names in workflow, here’s how we can make it work:
If you’ve seen a similar notification, I empathize with your pain. I don’t know that there is one solution to this problem, either, so I’m going to share a number of them we’ve used and hope that one (or all) of them will help you.
Basically a file is added through file explorer (a cloud library in OneDrive or SharePoint being synced locally to your computer) but then after a moment a notification appears which says “You now have two copies of a file; we couldn’t merge the changes in [filename]” and then the filename is appended with your computer name again and again until eventually the filename is too long and is harder to delete. Let’s not get to that point.
It’s not uncommon to want to use yes/no checkboxes when building Microsoft Flow conditions. [Field] is equal to “Yes” or [Field] is equal to true won’t work because it reads the Yes or true as a string rather than a value. So when the flow runs, even if the checkbox is checked (true), the run history says the expression result was false.
Fortunately it’s a simple two-step fix. Follow these steps to be able to use yes/no checkboxes as conditions in your flows:
I’m speaking about using Microsoft Flow and SharePoint Designer Workflows to streamline processes this weekend at SharePoint Saturday Kansas City, Sep 16, 2017
“Save” isn’t as familiar/intuitive to non-SharePoint users as language such as “Submit” can be. Change “Save” to “Submit” by adding a script editor or content editor web part (CEWP) to the newform.aspx page for your list.
When writing your own custom headers and footers, you probably don’t want/need that script showing in modal dialog windows too. It can look sloppy or accidental and may wrap oddly, as seen in my example above.
Luckily, it’s an easy fix.
We’ve all been there. One location on a shared calendar will be referred to by multiple people as 20 different things. Johnson Building Room 214 can be entered as “214,” “Johnson 214,” or “J214” to name a few. Canceled events stay on the calendar, sucking up real estate and waiting for someone to delete it manually. Items copied from another calendar make you pay for the convenience of a simple copy and paste by adding the “Copy: ” prefix to the item.
But with a single workflow, we can fix all of these and make our SharePoint calendars look more professional and polished without making more work for end users. This post will cover how we can use workflow to standardize naming of locations with workflow, delete events once they’ve been canceled and get rid of Outlook’s “Copy: ” prefix. You will need SharePoint Designer and appropriate permissions to create workflows to complete the following steps:
SharePoint Designer 2013 workflows verify workflow email recipients are part of your organization, while SPD 2010 workflows do not.