As with any design or development products, inevitably the longer you spend on them, the more you learn how to use the features. This also means that your solutions will become more elaborate. In the case of Nintex Workflow, does this mean that you start to over-engineer your workflows? Yes and no.
The goal of a workflow is to map out a business process. Some business processes are complex and require a complex workflow design. So processes are simple, but also require a complex workflow design. The reason for this is that Nintex Workflow comes with many out-of-the-box actions and if you also use Nintex Live, you have many more. If you want your workflow to withstand the test of time, then an elaborate workflow maybe the way to go.
Let’s say that one of your business processes requires that certain teams maintain a particular list. Once the project is over and the team is dissolved, you want to remove that list.
In this scenario, when a team is created you would look into creating a list for that team, and delete the list when the team is dissolved. What if for some odd reason, your team is called “Shared Documents”? I know…silly… but work with me:). Your workflow tries to create a list with that name and the workflow obviously fails because “Shared Documents” already exists. Another scenario is if your team is finished and one of the site admins deletes their list. When your workflow runs, it tries to delete a non-existent list and the workflow fails.
One way around this is to implement Error Handling. This is definitely a good solution. But it’s not always the solution. Why not minimize the chance of an error by checking to see if the list exists?
I could have implemented this check in the workflow I’m working on, but I’m sure that in the future I will need to do this again. One of my favorite development sayings – “Don’t reinvent the wheel.”.
So it’s time to implement a User Defined Action (note: User Defined Actions are only available in Nintex Workflow 2010). I’ll then be able to use this in any of my workflows.
User Defined Action – Brief
You can think of a User Defined Action (UDA) as a mini-workflow. It allows you build some workflow logic, publish it, and when you go to design a workflow, form the palette of actions you’ll find a User Defined Actions group. You simply drag your action from there onto your workflow. It behaves just like any other action.
UDAs are a good way of reusing without reinventing.
NOTE: if you update a UDA, you need to republish the workflows that uses that UDA in order to get the latest updates.
In order to design a UDA, firstly click on Site Actions and then at the bottom of the drop down menu, you’ll see a Nintex Workflow 2010 section. If you expand that, the last option is Manage User Defined actions.
When you get to the Manager User Defined Actions page, you’ll have the usual SharePoint Ribbon. If you want to create, modify, delete etc, this is where you do it.
For our purposes here, we’ll just do the Create.
When you click on the Create button, you’ll find you are provided with the Nintex Workflow designer. It looks and acts just like designing a workflow. The one thing you’ll notice, is that instead of a “Workflow Settings” button on the Ribbon, you’ll have a “UDA Settings”. Also, if you click on that, you’ll have another option which is Parameters.
Parameters are just like variables, except they have another type to them which is either an Input Parameter or an Output Parameter.
When a workflow uses a UDA, it can pass in data and also get data back. This is how you use the parameters.
Does List Exist – UDA
One thing to remember before we delve deeper is that the solution I come up with is not the only solution. There are other ways of doing things, but this is one way that has worked for me.
Firstly, we’re going set up our UDA parameters. In this scenario we have 2 parameters.
– Single Line of Text and is an Input parameter
– Yes/No and is an output parameter
Once we add the parameters, they should look like this:
I decided to use the Call Web Service action. This action can be configured to point to the SharePoint
web service. What I’m looking for, is to get a collection of lists. The web method to use is the
This web service call won’t get me a list of List names. It will give me results in XML form which I store in a Text variable.
(notice I’m using a Nintex Workflow constant called Site Admin Credential. That way, if I ever need to change the password for that account, I just need to update the constant and any workflow that uses this constant will automatically inherit the change)
We have a Regular Expression first, that removes an xmlns=”” namespace declaration form the XML because it always gives me grief with XPath.
We need to run an XPath query on it to retrieve just the List names. In this case, the attribute from the List node that I need is “Title”.
Our Query XML action looks like this, and the resulting List names will be stored in a Nintex Workflow collection variable.
Now that we have a collection of List names, we need to see if the list name we are interested in, is in this collection. Here we can use the Collection Operation action. It has an “Exists” operation. We store the result into our Yes/No parameter “ListExists”.
That is our simple User Defined Action.
Workflow that calls the User Defined Action
Now that we have designed the User Defined Action, we can test it out in a workflow.
Firstly, we want to create a text variable, and use a Build String action to store a list name in it. I have a list named Destination, so I’ve put that in the text variable.
In the Nintex Workflow designer, there is a group of actions called User Defined Actions. If we click on it, we’ll find that our UDA is in there.
We simply drag the action onto our workflow. By default this action will have a yellow warning on it in the workflow, as we haven’t finished configuring it. Remember, this UDA takes an input and an output parameter. We need to have a Yes/No variable that will store the output of this UDA.
Configured, the UDA looks like this :
We’ve inserted the text variable that contains our “Destination” list name. We’ve set the Yes/No variable as the output.
Finally, we’ll need to check the value of the Yes/No variable and act accordingly. Here we can use the Set a Condition action to check the value.
End result of the workflow looks like this:
We can now publish this workflow and run it, and we’ll see that in the workflow history, because we have a list named Destination, that we have logged “List (Destination) does exist”. In a real business workflow, you’d definitely have more workflow logic than this, but this is simply a test to make sure the UDA works.
Exported User Defined Action :
Exported Workflow :
Download the Workflow
This is a good start to enhancing Nintex Workflow and building up an arsenal of new actions that other workflow designers (users) can use. This requires no development (as you would need if you were developing custom actions), and the big advantage is that once you build such reusable UDAs, you’ll be designing better, faster and more robust workflows in the future.