Changing a site’s master page using REST via SharePoint Designer Workflow

As a follow-on to my previous post about how to create subsites using the SharePoint REST API, I encountered a scenario where a customized master page was already in existence and I needed to apply that to subsites created with my provisioning workflow.

<insert quick note about Microsoft Patterns & Practices>
Microsoft’s Patterns & Practices are awesome as they provide you with prescriptive guidance for how to customize SharePoint without encountering future collisions with the product team’s development path. However, there may be times where you deviate from that guidance (such as not touching the master page) and require a solution for changing the master page.
</end PNP guidance>

So, let’s get down to business.. You’re going to want to build a few dictionary variables:

1. MetadataMasterPage

Name Type Value
type String SP.Web

2. RequestHeadersMasterPage

Name Type Value
accept String application/json;odata=verbose
content-type String application/json;odata=verbose
X-HTTP-Method String MERGE
IF-MATCH String *

3. JSONMasterPage

Name Type Value
__metadata Dictionary Variable:MetaDataMasterPage
MasterUrl String /sites/yoursite/_catalogs/masterpage/oslo.master
CustomMasterUrl String /sites/yoursite/_catalogs/masterpage/oslo.master

*Now clearly you wouldn’t always point your MasterUrl & CustomMasterUrl to oslo, this is just an example. You would provide the actual path to the master page you are setting.

Another point – there’s two master pages – the Site Master & System Master. See the image below to figure out which one is which:

(Also note – you have to include both in your dictionary variable even if you’re just setting one to a different value)


Now all you have to do is create an App Step and include a “Call HTTP web service action” within it.

The URL is going to be: http://pathtotheURL/_api/web and the HTTP method will be POST.


Click the OK button, then right click the workflow action and select properties.

1. RequestHeaders = Variable:RequestHeadersMasterPage
2. RequestContent = JSONMasterPage
3. ResponseHeaders = new Dictionary, call is ResponseHeadersMasterPage


That’s it! Go ahead and run your workflow and behold the power of the SharePoint REST API. It’s awesome! 🙂

Here’s what the full workflow looks like with my URL blurred out:



Using SharePoint’s Call a Web Service action to Retrieve data from WordPress and Loop through the results

Last week I had the pleasure of presenting at the CT SharePoint User’s Group on “MacGyvering an Intake Process for Power Users” and I included a demo of SharePoint 2013’s call a web service action. Of course the Demo God’s took over and my workflow got stuck on starting. In true SharePoint form, I got home that evening and tried again and it worked perfectly. I hadn’t run across many examples of looping through non-SharePoint data sources, so I figured it would be cool to document my steps and share with anyone interested.

So crack open a brand new SharePoint Designer 2013 Workflow and follow along!

1. Create a new Dictionary variable called requestHeaders with two entries

Name: Accept
Type: String
Value: application/json;odata=verbose

Name: Content-Type
Type: String
Value: application/json;odata=verbose

2. Add a Call HTTP Web Service action to your workflow.

3. This is where you will want to deviate a bit from my example. So I decided to go with a very simple example of grabbing all of my blog posts for my Word  Press blog. I’m not going to cover it all here, but basically you should head over to WordPress and take a look at their REST API’s documentation for all the cool stuff you can get at – but for now, let’s just go after posts.

Here’s my URL for the Call HTTP Service action:

4. Right click on the call web service action in your workflow:
Select properties and you’ll want to set the following:

RequestHeaders – Variable:requestHeaders (Dictionary)
ResponseContent – Variable:JSONResults (Dictionary)
ResponseHeaders – Variable: requestHeaders (Dictionary)
ResponseStatusCode – Variable: responseCode (String)

*Please note you’ll need to create these variables*

5. Next you’ll want to figure out how many results your web service call retrieved. I personally like to create a step to store these next few steps but it’s up to how you want to organize your workflow. At this point, you’ll add a “Get an Item from a Dictionary” action to your workflow. In order to figure out what you’re doing to get from the Dictionary, you’ll want to understand what Word Press is returning from your REST call. Here’s a screenshot I took of what is returned from my call to grab all my blog posts. Ironically enough, each entry is stored under “posts” which is what you’ll want to retrieve in this next step.


So your step should match the below – you’re going to Get posts from Variable:JSONResults and output to a new Dictionary variable called dataset.

6. Next, add a Count Items in a Dictionary action. Pass it the variable: dataset and output to an Integer variable called resultsCount.

7. This next step isn’t always documented which got me stuck when I first tried to loop through the results from a web service. I had to recall my CS110 course where I first learned how to create a loop in C++, I needed a LoopCounter variable to help iterate through the collection results. In C++ this would have been my variable i so I could i++, in the land of SharePoint, I’m going to use an Integer Variable called LoopCounter.


Initialize your LoopCounter variable to 0.

8. Now you’ll want to add your Loop with Condition action to your workflow. I’m going to show you what mine looks like then break it down piece by piece.

loop step

8a. You’ll first set the condition so that the Loop with run while your LoopCounter variable is less than the resultsCount variable. Since you’re starting at 0, it’ll break out of the loop once you have reached the same count as the number of items you have retrieved.

8b. Add a “Get item from Dictionary” action and this is where you’ll put the posts([%Variable: LoopCounter%]) which is basically you retrieving each results from the JSONResults Dictionary. You’ll then output that to yet another Dictionary – I called mine ResultItem. Basically this variable has all the details for each result (in my case the post title, URL, etc)

I’m going to refer you again to the JSON results which gives you the parameter name for everything in your results item. The two parameters I want to grab are title & guid – title is obviously what I called my blog post, and the guid is the URL. Kind of strange they didn’t call it URL, but whatever.

9. So you’ll add a few more “Get Item from Dictionary” actions – mine were to get the title & guid and then output them to a variable. If you just want to re-display, make them string variables.Basically, I’ll give you the advice to consider what you’re retrieving and then set the appropriate variable to take action upon that. If I was pulling back a number parameter, I might store it to an Integer variable, etc..

10. Now you can choose to do whatever you want with these new variables. For simplicity sake, I’ll just log the values to be displayed in the workflow history.

11. Once you’re done playing with variables – don’t forget to increment your Loop Counter. Insert a Do Calculation action, pass the LoopCounter variable, and have it output to an Integer variable. I called mine calc1 – but you can call it whatever you would like.

12. Assign the value of LoopCounter to calc1 (basically it’s LoopCounter++ – increment by one)

13. That’s it! Test your workflow out and have some fun..

14. (Extra Credit) have your workflow create a new list item using the variables you grab – so for this example the Title + GUID..

Example of writing title to workflow history


Summary: This post is hopefully helpful at demonstrating how to use SharePoint 2013’s Loop function along with the Call a Web Service action. This functionality is pretty powerful, as you can see it even stretches beyond the limits of SharePoint. The one key point to using Word Press as a data source is that the API accepts anonymous requests. Remember that workflows run as the user who initiates it unless you include App Steps (whole different blog post)