While planning out a new series I want to do around PowerApps and Flow I realized one of the things I needed to do was get the value of a lookup field into a text field. Now we all know that using a calculated field for this isn’t going to work since they can’t see lookup fields. Yes I could use a choice field instead, but in this case I wanted a lookup field so that the users could easily update the choices from the lookup list. There are a number of examples of doing this with a SharePoint Designer Workflow. So I got thinking, but about Flow? I found a number of examples of users asking for ways to do this or having problems doing it, but nothing really concrete. So I decided to write something up quick as it really is very easy to do with flow.
These days it is really easy to create lists and libraries to store data and documents. It is also very easy to build metadata to support the information you are trying to store. However, as I have stated before it is also very easy to set things up incorrectly. This next post in my Power User Best Practices is going to cover what you should and shouldn’t do with a SharePoint List and Library.
In my previous post on the different ways to determine the return message from a REST API call in a SPD workflow I covered using a test list and Fiddler to build your web call in a SharePoint Designer workflow. In this post I want to discuss manipulating REST API calls in SharePoint Designer 2013 workflows. Basically I want to show how you can determine what your read string is going to look like based on the values coming back from SharePoint.
Years ago when Microsoft released it’s latest version of SharePoint Designer, it came with a few enhancements that really made building workflows with Designer more robust and efficient. One efficiency enhancement was the ability to copy actions, steps and even entire stages within the same workflow or even between workflows. Microsoft also allowed for the ability to move back and forth between stages instead of continuing down a parallel path (called a state machine workflow). While the addition of state machine workflows to Designer (previously only available in Visual Studio workflows) is great; in my opinion the best (by a very small margin) addition to Designer is the ability to call web services. As your queries get more and more complex however, knowing what is coming back into the workflow can be filled with frustration as you try to determine how to get the data from the response content. While I it isn’t a new concept, I wanted to discuss handling REST responses in SharePoint Designer workflows. Or at least how I do it. The method I use is pretty straight forward and very easy to implement.
All too often when building workflows in SharePoint Designer there is a need to pause the workflow for a duration of time, or while waiting for values to change within SharePoint list\library. Microsoft has provided methods or actions within a workflow to accommodate this for quite some time. The method to accomplish while similar between versions has changed with the latest iteration of SharePoint Designer. For this reason I wanted to discuss waiting in a SharePoint Designer 2013 workflow today. I know that most are now moving to SharePoint 2016 or SharePoint online, but while Microsoft has released newer versions of SharePoint, it hasn’t released a new version of Designer since 2013. So whether you are on SharePoint 2013 or a later version, this post is relevant for the foreseeable future.