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:
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 http://projectna.sharepoint.com/sites/pwa. 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…..