A Project approval by Artifact Solution

Posted By Posted by: EPM Partners on February 20, 2017

Blog_Blue Bar Skinny

Recently, as I gather key requirements for Project Online implementations a trend has been in approving projects based on company template and predefined artifacts. Some of the artifacts include executive summaries for project financial approvals, or a project brief for a steering committee and technical endorsement. Regardless, the artifact represents the project per type of stakeholder. What is an approach to make Project Online a handy tool to manage such key documents? I’ll provide a brief outline on this blog of what works really well. A full on guide would require a long series of blogs or a book. However, if a good solution architect is reading this, a light bulb may shine on top of his/her mind and will then be able to run with it.

For the record, I still can’t decide between the term “artifact” and “artefact”. Apparently, both are acceptable spellings. I am leaning towards the “artifact” though, I like the “I” between art and fact. The use of the term project document sounds too generic, I think most would agree, especially those versed in SharePoint Content Types. In my thinking, there are project documents aka supporting artifacts but then there are request documents, they are more official and possibly legally binding, so to me, artifacts sounds better, or as my tween son says, it is more MLG.

So to get started with solution outline, take note of the three high-level requirements we must meet.


Now, let’s look at what we can do out-of-the-box for the three requirements.

Req 1: Auto-generation of data-driven documents is actually possible OOTB, one could have a word template bound to a content type with mapped fields to the hosting document library.  Then, using a SharePoint 2010 workflow, you can create an item in the library of target content type. After the item is created, there will be an auto-populated word document. Look the technique up, here is a 10 min youtube video: https://www.youtube.com/watch?v=T3IXQ2cW5L4 , note only 2010 workflows will work and this approach works fine in office 365.  I recommend this approach if data source of word document is just one data source. Unfortunately, supporting multiple data sources per artifact and ability to convert to pdf are just not there. A component will need to be added to generate the artifact. There are a handful of third-party products out there to assist. I’ll highlight what I did in a little bit.

Req 2: Record decisions by stakeholders, that sounds like a simple requirement. It is but please note, to the Stakeholder, what he/she reads in the artifact is what’s approved. For an aggregate view usable by power BI users, values cannot solely be in contents of a file, that number must be readable from another source. I recommend using a set of SharePoint fields of the file. So if you are following the OOTB file generation from Req 1, you are still solid because the data is visible in both locations. Regardless, we must ensure properties are written to file and Sharepoint fields. There is no other OOTB way to do this.

Req 3: This one is tricky, but think of this. OOTB, We can get a project workflow to initiate a 2010 workflow that can create a document then … then.. then… then.. but no, OOTB will not be friendly, customization is required.  Most may agree, this should almost be built into the product, but it isn’t common enough I guess.

So full OOTB is out of the question. Some custom development is required. There are numerous ways to go about this as always when customizing.  If you are hiring a vendor, they can easily make a space ship but note there are really only five fairly small custom components to make and should not span outside of the standard 2-week development effort. Of course, if you are trying to generate a 100-page artifacts, that is a whole different ballgame.  The artifacts I have been tasked to generate range from 1 to 20 pages and include PWA, Project Site, and Excel data. A basic solution will need the following five custom components.

  1. A custom web api applette to generate artifacts.
  2. A script component to place on a project pdp for use by managers to generate artifacts
  3. A script component to submit documents
  4. A script component and/or external workflow action to react to decisions
  5. A script component to incorporate variations

Other OOTB ingredients that are essential to solution are

  • Document content types defined for a branch of approval artifact types.
  • A library or set of libraries to manage draft artifact and submissions of artifacts, sharing defined content types. This can be in the Project Site for draft and a central for submitted. I highly recommend the central repository, otherwise, a data warehousing solution will be required for Aggregate PowerBI view.
  • A document library to hold document templates.
  • Workflow per type of artifact and applicable stakeholders.

See below for a sample component model of a solution. In this instance, I went with the workflow route to respond to approval decision.  I decided to create an external project updater action to call from a non-project workflow. Another variation of this would be to update the project from a custom button instead of workflow. Either or both should satisfy your requirements.

Figure 1- Project approval by Artifact Solution Component Model

The magic element to my solution that pulled everything together was how I generate documents. Component number 1 (red block) in the diagram above. Word documents are kept in a simple document template library. Inspired by Angular, a technique invented by Google on how to template websites, I applied the same to word authoring and binding of data to these templates and save somewhere per endpoint input.

You can use your own templating standard, but the double handlebars are pretty well-known. In the word templates, there are fields wrapped around in brackets like {{FieldName}}. One of the few responsibilities my provider hosted web app has is to extract template, search for bracketed text and replace with matching data then save in destination. For document rendering, I have used an array of third party tools, to include Aspose and Syncfusion. Syncfusion has been my favourite so far, but both can do the job. There are some good free open source document generators out there too. Maybe someday I will make my WordAngular or Wrangular component open source in github. Bottom line, the web app provides a way to apply data to templates and updates document key fields to meet three requirements.

So as you can see, custom development is needed, but when done right, it makes the whole implementation of Project Online a very elegant solution. Hopefully, one day Microsoft will give us a range of Flow apps or something similar to help meet requirements. Till then, use this model as a guide.

Blog Posted In Blog Posted In: Uncategorized
Blog Posted In 

Leave a Reply

Your email address will not be published. Required fields are marked *