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.

Advertisements

2017-09-17_13-59-37

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:

This tutorial works for any Microsoft-Flow connected social media platform, but we’ll specifically go through the steps for setting up a Twitter tweet and Facebook post submission system. We’ll be utilizing Microsoft Flow’s new “Approval” feature. Here’s our (and maybe your) scenario.

  • We want to allow broader participation in social media content, while still maintaining a close grip on the quality and management of our platforms. This is more inclusive, increasing engagement and also giving you more eyes and ears throughout the organization while maintaining control
  • Individuals will submit their ideas (can be via direct email to a list, a form, PowerApp, etc. – we’ll use a list)
  • Social media manager or team will approve or reject submissions which will then be automatically posted to the applicable social media network if approved. See bottom of post for additional challenges to enhance this system.

Let’s get started!

flow1

Perhaps you, like me, built an exciting Microsoft Flow workflow and let it go into the wild without much additional thought. But at some point, you drop a lookup column into the mix and your Flow stops working. It tells you the field is not supported in query, even if that specific field isn’t being utilized in the Flow. I believe this has something to do with REST, but we won’t dwell on the cause – let’s get to the workaround.

The scenario I’ll be using is my cross-site publishing alternative using Microsoft Flow where I’m basically copying data from list items in one site collection to create new list items in a different site collection. This is helpful when someone does some sort of data entry once, and other people are then entering much of the exact same data. This copies all of the overlapping data to a new list item for the second site collection to reduce duplication of work.

It sounds simple but with a lookup column in the destination list we get the error. For this I’ll be using SharePoint Designer and Microsoft Flow (of course) in combination, though you could certainly try it all in Microsoft Flow. I just find parts of the process simpler in SPD. And while your origin data may be different (MailChimp, Twitter, etc.), and your exact scenario may differ, this workaround should still have value in concept.

I recently ran into the following error message in Microsoft Flow that was triggered by a SharePoint – modified list item flow: “The query to field ‘/fieldname/LinkTitleNoMenu’ is not valid.” You’ll see this message in some cases when lookup columns are being utilized on the lists you’re referencing in Microsoft Flow.

This error was caused, at least for me, as a result of setting my “destination” list’s lookup column setting to display as Title (linked to item) instead of just Title. The following details the steps involved in fixing it.

You may have several forms or lists using dropdown menus across your site that you would have to update if, say, an individual resigned, or a department changed its name, or a building relocated. Manage this type of information (individuals, departments, buildings, etc. frequently used in lists and forms)  in separate lists that we’ll then use to create site-wide lookup columns to replace the many individual dropdowns across our sites that are repetitious. Basically, we’ll update the information in one place and know that it’s updated everywhere it’s needed across our site (or site collection if you’re familiar enough to go the extra mile with collection content types or Microsoft Flow, if your permissions aren’t at the site collection level).

listcopyprocess.JPG

It’s not easy to show a list (or part of a list)  from one site collection on another. There are data view web parts you could try in SharePoint Designer, content search queries  and page viewers in SharePoint web parts and then some scripting methods you could try, but I, in my enterprise environment, had no luck with those. This method, however, utilizes Microsoft Flow and works flawlessly. Here are a couple great features:

  • Permissions are completely flexible. Set the “new” list to view only or whatever permissions you like while keeping tight control over the original. People will not be able to access the original list or site collection but they’ll see your up-to-date info you’re wanting to share.
  • You can set this up so it’s a one-way publishing experience so updates on list 1 show on list 2, but updates on list 2 don’t show on list 1 OR you can set it up two-way so each list will update the other, creating a shared list experience without allowing permissions to access each other’s site collections

So let’s get started!