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:



Creating subsites using REST API from SharePoint Designer Workflow

I absolutely love SharePoint 2013 style workflows solely because of the Call Web Service action. It is hands-down one of the coolest features as it allows you to build some really amazing solutions.

I’m documenting this for my own benefit but if you happen to be in the same boat trying to build your own solution – I hope this helps!

Starting point: make sure that you have configured workflows to be able to run with elevated privileges in your site collection. Rather than re-invent the wheel, just follow this Microsoft article. From there, create a brand new Reusable workflow. The first step will be to create a variable called RESTUri of type string and have it be combining the Workflow context current site URL + /_api/web/webinfos/add. This is going to be URL that the Call Web Service will access:


Next you have a few Dictionaries to create:

1. RequestHeaders which will contain both Accept & Content-Type with the value of: application/json;odata=verbose


2. Metadata which will contain just a single entry of type as string with the value: SP.WebInfoCreationInformation

3. JSONRequest which will contain a bunch of different values:

Name Type Value
Url String This is the site name in the URL example: http://sharepoint/sites/site1/subsite (reference the list column value)
Title String The Site Title (example: Jared’s Awesome Site)
Description String The Site Description (example: Jared’s Awesome Site is a world class SharePoint blog)
Language Integer 1033 (for English, others here)
WebTemplate String STS#0 (Reference this blog for more choices)
UseUniquePermissions String true/false Рif you want to inherit permissions go with false
__metadata Dictionary Workflow Variable:Metadata (defined earlier – make sure it’s a double _ underscore)


4. Params which will contain a single entry called parameters as type dictionary with the value of the JSONRequest variable.


Great! Now that you’ve set all that up, create your App Step and add a “Call Web Service” action inside of it. (If App Step is greyed out, please see here again)

You’re going to want to click on the word “this” and insert the variable RESTUri in the “Enter the HTTP web service URL” spot and then specify this as a POST method.


Click ok, then click on the word “request” and select the Params variable you had created. Your call web service action should look like this now:


Now, right click on the call web service action and click the properties button. Map the RequestHeaders to the variable you’d created, create a new dictionary called ResponseContent and map that to the ResponseContent.


Then click OK.

I like to add a step after the web service call which logs the¬†responseCode variable to the workflow history so I know if it was successful or not. When it’s not and I’m troubleshooting, I’ll create an e-mail task which then sends me the ResponseContent so I can get more information about the error that’s being thrown.

If you’re good, go publish your workflow and click OK at the prompt about the App Step.

This is what my workflow looks like at this point:


Now go attach this new workflow to your list which should have columns for: Title, Description, and URL.

One other fun little tidbit which I’ll give thanks to Fabian Williams for is that the AppStep can be a little tricky. If your workflow is throwing “Unauthorized” errors, check out Fabian’s blog post.

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)