This blog started way back when with a post on creating status reports. Back then, my go to method was to leverage an InfoPath form embedded in a Project Server PDP. The key was to pull the ProjectUID from the PDP URL, drop that into a status report entry in a custom list, and then surface the status reports on another PDP. This concept worked reasonably well, and I managed to leverage it for a number of use cases throughout the last couple of years.
Of late, I’ve been playing with SharePoint Designer workflows, and I came across another method of creating status reports. In fact, status reports are merely one use case. The techniques that this and several future blog posts will show will allow administrators to create a whole slew of custom actions that could augment the traditional Project Server experience.
Note that nothing I am writing about is specific to the Project Online or Project Server on-premises. This could be applied to either platform.
Creating the Status List
To support this scenario, we will need to create at least two workflows, and at least two custom lists. The first list will be our status update list. I’ll create that as a custom SharePoint list and add columns for the Status, Project UID, Project Name, Project Start Date, and Project Finish Date. The reality is, of course, I can add any fields that I would like.
This list will be used to capture the status updates.
Creating the Project Action List
Next, we will create the list to store our custom project actions. This list will be a custom Link list. We will also use this list to host the status reporting workflow. To this list, we add a column for the Project UID. Ignore the two crossed out columns, as those were used for testing the workflow.
That’s pretty much it for the blocking and tackling. In the next post, I’ll talk about how to read project data in a workflow, and write it to the status list. We’ll follow that up in the third post with a discussion of how to create URL triggers for the workflow.