The idea of a "dashboard" comes up a lot and for me, I generally cringe at the thought. Not because it is difficult to implement, but because it is difficult to implement well enough so that the customer uses it frequently enough to get value out of it.

Scenario:

I recently had to deal with such a case with an internal customer where they wanted a form to be submitted on a child site and then certain pieces be promoted up to a parent site list upon submission. So how do we accomplish this? I used Web Services within a Site Collection workflow that is triggered by a content type. Simple enough, but requires a bit of knowledge in regards to what is expected and what to look for (a lot of trial and error )

Setup:

I am not going to go into too much detail about Content Types, but I recommend knowing how to use Content Types and how to apply workflows to them. Perhaps that will be another blog for another day. This is what I am working with:

Master List on Parent Site - this list is used to build views from data that is coming from multiple child sites. Here is where you want to define the columns you want to write to and how you want to build your views/dashboard. I added columns to mine so that I can match records based on project name and ID. This allows everything to be in one location, but sometimes you need to separate out data, so do what makes sense to you.

Forms Library with specific Content Type on Child Site - this library will be where the form is submitted to and certain columns are promoted out. I used InfoPath for this only because I cannot figure out how to promote out columns to a library using Nintex Forms! If you do know or have any thoughts/ideas on this, please let me know in my question Promote form controls to another list​. In regards to the content type, it is empty (there are no site columns associated to it), as we are leveraging it so we can easily identify content as it is being added to multiple sites.

Site Collection Workflow - this workflow will trigger anytime something new is created with the specific Content Type. This is the "man behind the curtain"; the one that does all the heavy lifting!

The Process:

The overall flow of this process is simple enough; a user fills out a status report and submits it to a library. The workflow is triggered (because of the content type) and then interrogates it to get additional data to push up to the master list. So lets dive into the workflow actions!

The Workflow:

First let's open up the first action set. Ultimately, we need to query the library for the data we want, but before we do that we need to know how to do that.

We can use the web service action and call the GetListItems method from ..../lists.asmx. We will need to feed it a few items at a minimum:

List Name

You could use a variable here if you want to leverage this for multiple list updates

Query (XML)

What item(s) are you going after? For this example I am going after the Current Item so I can use the ID like this:

View Fields (XML)

What fields do you want back? Simple enough, but be careful of what the columns are named as the internal name may be different than the display name (wasted a lot of time figuring that out!). Here is what I am using:

Query Options (XML)

How you want it displayed. I do not use anything here, but still need to pass in something. I added a build string action in the event that something needs added later I have something in place already. So for now I am using:

Once this all gets packaged up in XML and saved into workflow variables, simple add them into the Web Service action and save the the result set!

But now all we have is a bunch of XML data, so what's next? If you are thinking coffee then go get some! If you are thinking Query XML you nailed it!

With the result set we can pick out the specific data that we want to use and push up. This can be tricky if you are not familiar with using XPath but there are plenty of examples that you can follow such as How to extract output values from SOAP response message with Query XML action? or Dictionary Part 2 - Query XML results into a Dictionary​. I generally have to lookup the exact XPath Syntax and reference that site often.

Once you have a handle on that you can add an output for each point you want to grab like so:

Almost there! We queried the library for the item and grabbed the data. We parsed through the data to get it into a format that we can leverage. Now we just need to update the Master List. Call another Web Service!

Just like before, we need to know how to feed the web service so we are updating the right item. This time since we are updating it is pretty straightforward; need the list name and updates.

List Name

You could use a variable here if you want to leverage this for multiple list updates

Updates (XML)

The updates to be made on the target list. Here is what I am doing:

I am finding the specific item to update and then pushing in the variables that I captured from the XML.

There are other Cmd's that can be used such as New and Delete if you needed to add a new record or delete something rather than updating it. I would recommend good 'ol MSDN for more information.

Final Thoughts

With everything in place, we can now have users submit a form to a library on a child site, and have specific columns be promoted out of the of the form and up to the master list on the parent site.

This allows us to build views for dashboards so that (in our case) executives can see, at a glance, the status of all projects from a central location.

With this workflow, we can also add in notification steps if needed, or even updates to other locations. Most importantly, because it is being triggered on a content type, we can apply this content type other places within the site collection and be tied into this workflow with almost zero effort!

Please let me know what your thoughts are on moving content around and out of sites and how you have leveraged web services!

Until next time!