Application Lifecycle Management with SharePoint Workflows

  • [アーティクル]

This post is mainly for those who want to achieve email sending from SharePoint Designer Workflows. (If you don’t want to read through all the drama, jump directly to the Falling Action section.)

Exposition

In an enterprise environment developing SharePoint Workflows on the production environment might not be the best thing you can do. Of course if you are a superuser and you are developing a workflow for your small team, it might still be a solution, but if your solution is business critical... Well... You might wish to have some kind of Application Lifecycle Management (ALM) for your workflow.

(notesign Don't Be Afraid notesign)

Rising action

With the introduction of SharePoint 2013 Microsoft introduced the interchangeability feature between SharePoint Designer and Visio 2013 Professional. What does it mean? It means that you are able to create your Workflow in Visio 2013, then import it into SharePoint Designer and the other way around. Sounds fancy, but what does it really mean to us?

Climax

It means two things:

  1. One does not need to be a SharePoint superuser to be able to create a business logic that is to be implemented in SharePoint.
  2. One can port their precious Workflows between environments with ease.

Too good to be true, you say? Well... Indeed there are some things you need to keep in mind.

Act 1

First and foremost, the SharePoint 2013 style Workflows are bound to GUIDs. This post's target audience is the superusers so I won't go into the details on why and where. When porting your Workflow between DEV, TEST, UAT and PROD environments, you have to use the same GUID for :

  • the actual list where you deploy your workflow to,
  • the Workflow History List,
  • the Workflow Task List.

Also, you have to make sure that:

  • the association scope between the SharePoint site and the Workflow Manager farm is different, because that's another GUID.

Act 2

So let's put it together. What steps do I need to make this thing work?

  1. Create the basic structure of your solution in your DEV environment, including the
    • List(s) that you will use to store your data
    • Workflow History List
    • Workflow Task List
  2. Port your list to the other environments (TEST, UAT and PROD). For this you can use
    • Content Database transfer
    • SharePoint solution that deploys the above lists with the same GUID throughout the environments. (This is the option you have to choose when you are in a Hybrid scenario, as you cannot just port the ContentDB to SharePoint Online.)  
      (Seems this is not an option unfortunately. Thanks to my colleagues Westin Kirebel who highlighted this, and Istvan Fabian, who helped with the clarification. Sorry.)
  3. Have your Business Champ create the Workflow in Visio 2013. (This is an optional step, if you are the Site Administrator and you know what you want to achieve.)
  4. Import the saved Workflow into SharePoint Designer - or create your own if you skipped Step 3 - and bound it to the List. Map the fields and do whatever other modifications are needed to make the Workflow working in SharePoint.
  5. Export the Workflow from SPD.
  6. Copy the VSDX file to your other environments.
  7. Import the VSDX file in your other environments and bound them to the same lists.
  8. Enjoy your solution.

 

Act 3

Doing it once is not a big deal, since ALM is all about constant changes and updates, right? Yes, exactly. The beauty is that from this point whatever modification you do in your DEV environment can be easily ported to your other farms.

Those of you who paid attention so far might have noticed that I did not mention the columns so far. Indeed I did not, because the GUID of the columns are irrelevant. Only the internal name matters. How cool is that?

When you do subsequent export-imports between the environments, you will get a nice warning window in SharePoint Designer, reminding you that the VSDX file that you are about to import contains an update to an existing Workflow and asks you if you want to update it. Of course you do, since this is exactly why we are here, no? Of course we are.

 

Falling Action

The above described action works just fine with SP2010 and SP2013 style Workflows as well. Unfortunately it works with on-prem only as you cannot create lists with a specific GUID and you cannot port the ContentDB to the Cloud.

Life is good. (notesign I feel good notesign)

Dénouement

As you can see, the built-in SharePoint Workflow infrastructure is flexible enough to implement an Application Lifecycle Management easily. For how long? That we do not know, as - at the time of the writing of this post - Microsoft has no clear statement of the future of the built-in Workflow infrastructure, the only thing we know is both the 2010 and 2013 style Workflows are deprecated.

One thing we know for sure though; Future is the Cloud after all.

(notesign Blue skies notesign)