I love Nintex, and I am not just saying that as a Nintex vTE. My journey with Nintex started in 2007 and has gone from strength to strength, but the best most useful thing about Nintex over OOTB sharepoint workflow and any other solution I have found is the REUSABILITY and DEPLOYMENT. Everything from reusable templates to snippets and those all important EXPORT / Import of NWF files to move the workflows.

One of my favourite tools is the USER DEFINED ACTION (UDA). This, for those not in the know, is a reusable action set (kind of like a workflow) that allows you to group a subaction together and use it throughout your site / site collection. When you make an update to the UDA, it updates in all the workflows where it is deployed, making it far more practical than snippets and templates.

I have recently started using the UDAS in production and noticed a couple of challenges in the deployment process, but most recently I found an example that had me stumped for a while. By default you can export a UDA and import it to a new environment, this works the majority of the time, however in certain instances where you have site collection constants and variables you might have to follow this same approach I am gonna talk about. (Essentially sometimes when you import a UDA it just doesnt work).

The strange example I had was when one of my staff members created a UDA that referenced another UDA. Technically this shouldnt be possible as you do not have access to the UDA’s menus when designing a UDA. BUT what I think might have been overlooked is that you can export a WORKFLOW that uses UDAs and import that into a new UDA, thereby allowing a UDA to be referenced in a UDA (its all starting to sound a bit like Inception). What you will find though is when you try and deploy that to a new environment your UDA that references the other breaks saying that it cannot find the other UDA. So how do we salvage all the work we have done. This all comes down to GUIDS / Primitive keys.

For ease of explanation we are going to assume we have UDA-A which references UDA-B. These are the steps we will take to get this working:

  1. We will deploy UDA-B as per usual – Export the UDA and import into the new environment, Do this by exporting the UDA, do not open the UDA and click Export as this will export the workflow in the UDA to an .NWF file, we want a .UDA file. Great now if we export UDA-A and try and configure UDA-B action it will fail
  2. Go into UDA-A and export the workflow to a .NWF file
  3. Open the NWF file in notepad (or Visual Code or any other IDE)
    • Do a search for the name of UDA-B in the code
    • From the name continue through the code until you find the next PRIMITIVE VALUE with a GUID something like dbcff347-521a-4973-bb85-be081d3fece7 – store this value somewhere as OLD GUID – we will use it later, essentially this is the GUID that identifies the UDA-B in the original environment
  4. In your New site create a site workflow with one action in it – the actions should be UDA-B
  5. Export the workflow to .NWF file and repeat the steps from above to get the primitive value guid – something like 75726eec-e663-4ddc-94da-ad59f9a58caa – store this as NEW GUID – this is the GUID for UDA-B in the new environment
  6. You now have the OLD GUID and the NEW GUID. Open the UDA-A .NWF file and do a FIND and REPLACE using the value of the OLD GUID and replacing with the NEW GUID and save the file as your new NWF file
  7. Create a new UDA in the new environment that will become UDA-A
  8. Import UDA-A .NWF with the changes we made and VOILA, your UDA-B is configured correctly and working in the new environment

Well that took me a while to figure out, but since using it I have used it a couple of times, just today my team came to me wondering how to deploy this, so I figured let me right a blog so EVERYONE will now know how to deploy this.

Craig Tarr
Craig Tarr
COO, lover of jQuery, JavaScript and all manners of application generation, Nintex vTE and advocate of everything out of the box.

Leave a Reply

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