Manipulating REST API Calls in SharePoint Designer 2013 Workflows

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.

Understanding the Data Coming Back

Let’s quickly compare the SharePoint and the Fiddler response I used as my example in the last post:

{"d":{"results":[{"__metadata":{"id":"Web\/Lists(guid'a97121d6-1f42-4d92-8b64-d8b26c230468')\/Items(1)",
"uri":"https:\/\/<siteurl>\/_api\/Web\/Lists(guid'a97121d6-1f42-4d92-8b64-d8b26c230468')\/Items(1)","etag":"\"3\"",
"type":"SP.Data.<ListName>ListItem"},"BusinessUnit":{"__metadata":{"id":"c1eefd00-05e5-4100-bc15-26f0c9a6d225",
"type":"SP.Data.<sitecolumn>ListItem"},"Title":"<Item Title>"},"Approver":{"__metadata":{"id":"3ebf36d7-89cb-4361-8981-bc00341b324b",
"type":"SP.Data.UserInfoItem"},"SipAddress":"<email address>"}}]}}

The results are actually very similar.  Let’s look at the SharePoint list response a little better.  If we focus on the opening and closing brackets we’ll see a similar pattern arising:

{"d":{
  "results":[{
      "__metadata":{
           "id":"9b3e9004-9606-426d-a63f-1a442b450f8e",
           "uri":"https:\/\/drevsponline.sharepoint.com\/_api\/Web\/Lists(guid'f25b29b1-13a6-4e77-a99f-19c24bbe4a89')\/Items(3)",
           "etag":"\"1\"","type":"SP.Data.ApproversListItem"
       },
      "Approver":{
           "__metadata":{
                "id":"48f0ec73-4ae8-48d2-8861-570a63af6fbf",
                "type":"SP.Data.UserInfoItem"
            },
           "Name":"i:0#.f|membership|spo_testuser@drevsponline.onmicrosoft.com"
      },
      "Title":"Finance"}]}}

If you use the brackets as “break points” in the SharePoint List response you will see it is almost idential to how it is organized in Fiddler.  This means when we are reading from the response either tool can be used.  Using the SharePoint test list and workflow comes in handy though if you aren’t able to use a tool like Fiddler or you want to test how you handle the response

Manipulating REST API Calls in SharePoint Designer 2013 Workflows

When determining how you are going to get the data you want, you basically just need to consider that each open bracket (in the SharePoint response) or each indent in the Fiddler response is another level you want to access.  And in the read string that corresponds to a forward slash “/”.  This means the read string for the login name (Name field in the response) would be: “d/results(0)/Approver/Name” (the 0 indicates we just want the first entry if there are more than one).  There’s a final slash after Approver because the Name field is within the Approver element.

So let’s test this out:

I have updated the workflow based on the above.  So now the entire workflow looks like this:

and we get the results:

So as you can see it’s pretty straight forward to determine how to get the rest response in an SPD workflow and also how to build a string to read from it.

 

Thanks for reading!