Creating Status Reports with Project Online and SharePoint Designer (Part 2)

In the last post, we created two lists, one to hold the workflow trigger and one to capture the status of the project.  In this post, I’ll run through how to leverage workflow to capture project data and then store it in the status list.  To do this, we’ll need to fire up SharePoint Designer and point it at our PWA site.


Create a new workflow and assign it to the Project Actions list we created in the previous post.  Deselect the option to Automatically update the workflow status to the current stage name.

We also need to add a multiline parameter to the Initiation Form called status.  The Initiation Form is important because it can be called through the use of a simple URL.  We will capture this URL and embed it in a PDP to trigger the status reporting workflow.


The workflow will now be comprised of two stages:

  • Capture project data.
  • Create the status list item.
  • image

Consuming Project Data with SharePoint Designer

To consume project data, we basically need two actions within the stage….a Call action and a Get action.  For troubleshooting, we also want to log all transactions to the Workflow History list so we can trace when things fail.


We configure the Call action as follows (for my tenant, which is  You’ll need to plug in the name of your own tenant.):


See how the Call action is pointing to the OData repository and then plugging in the Project UID field from the Project Action list?  Feel free to test this out by entering the URL into your browser, but substituting an actual Project UID for the lookup.

The other parameters in the Call action can basically be left blank, although I did name the content of the response “ResponseContent.”  This will be the dictionary of results – or each of the project level fields for the designated project.

We then need to Get the appropriate field from the ResponseContent dictionary and push it into a workflow variable.  Just follow the OData naming convention to identify the correct field name.  In this case, I am using LINQPad to assist in navigating the data structure.


Finally, write the new variable to the Workflow History list.  This will support troubleshooting efforts.

Now repeat the Get and logging actions for each field we need.


From there, we just need to create the status list item to store the data.


That yields an entire workflow that looks something like this:


Publish that workflow, and we’ll come back to it.

Next up, we build the trigger for this workflow and add it to the Project Action list…..

Creating Status Reports with Project Online and SharePoint Designer (Part 2)

3 thoughts on “Creating Status Reports with Project Online and SharePoint Designer (Part 2)

  1. Since someone brought it to my attention – note this solution has not been exhaustively tested. In particular, the security model could be an issue, i.e. it is assumed whomever triggers the workflow has access to the OData. In theory, you could emulate those permissions using an App Step (fka impersonation step)….but at least as of this writing, I couldn’t get an app step to read OData. Stay tuned as I would imagine Microsoft is working on this.

  2. Indresh says:

    Hi Andrew ,

    Can you please explain in detail how you used project name, project start date and project finish date in get step in workflow .


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s