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.
This weekend I had the privilege of speaking at the SharePoint Saturday Conference in Vancouver. At the conference I spoke on no code solutions for SharePoint Business Connectivity Services and the different features you had access to out of the box. It was a great experience and one I hope to repeat in the future. This presentation seems quite popular as I will be giving it again at the SharePoint Saturday in Calgary and the Prairie Developers Conference in Winnipeg.
As promised for all of these sessions I have attached the slide deck here for you to download for reference.
Thanks for reading.
Previously I have discussed SharePoint’s Business Connectivity Services specifically the External Content Type (ECT) and the External List. Basically an ECT is a mapping of all the data that you want to surface from an external source into SharePoint. An external list is where that ECT is surfaced into once you get it into SharePoint. An external list is very similar to a regular SharePoint List, but some features are not available. Some features that you don’t have include the ability to add or delete columns, quick edit, and most of the social specific features. You can find a complete list from Microsoft here.
Today I am going to illustrate to you how to create an ECT and an external list while making use of the secure store entry I showed you how to create previously. Today’s demo is going to be a completely “no-code” solution. My intention is to illustrate some code based example in a later blog post, but today we are strictly doing this without writing any code.