Caroline Sosebee is a Senior Software Engineer at ThreeWill. She has 30+ years of software development experience and a broad scope of general IT knowledge. At ThreeWill she has a proven track record of quality consultative and software development skills, focusing on the design and implementation of SharePoint solutions, both on-premises and in the Microsoft 365 cloud.
Introduction to Nintex
I’ve recently had the opportunity to work on a small project that involved using Nintex workflows. This has been my first ‘real’ exposure to Nintex and I’ve found it to have some really cool features that you can’t find when working with regular SharePoint workflows. I thought I’d share several of them with you today.
Woohoo! You can attach a document to an email notification! What a lovely thing this is. For this project, we needed to be able to email a PO to the vendor after it was uploaded into a document set. This isn’t possible with out of the box SharePoint workflows, but is extremely easy with Nintex.
Once you add a Send Notification action to your workflow, it’s as simple as clicking the Add Attachment link.
In my case, I needed to send the file the workflow was being run on, so I used the Item Property called ‘Encoded Absolute Url’ to pick up the URL for the selected file. A bonus is that you can add as many attachments as you like. You can do this by specifying multiple URLs separated by a semicolon, or by loading all your URLs into a collection variable and using that instead.
TIP: And while we’re talking about email notifications, there’s one slightly annoying option that is turned on by default, but luckily has a setting that will give the developer full control over it. When an email is generated, it automatically adds a header and footer to the email body around your text.
To turn this off, you have to go into Central Administration and click on the Nintex Workflow Management link found on the left navigation bar. Then select Global settings and scroll down until you see the option for ‘Enforce message header and footer.’ This defaults to Yes. Change it to “No” and then you do an IISReset to make the option active. Once reset, a checkbox will be displayed at the bottom of the configuration screen for the Send email action, allowing you to decide if you want to include the header and footer in this particular email. For emails going out to external folks, you probably would not want to include the system generated header and footer, but only have your custom content.
Query List Action
This is another very handy tool in the Nintex Workflow Actions set. I found it extremely helpful when working with a document in a document set. I not only needed to attach the document to the outgoing email notification, but I also needed to include some of its metadata in the email body itself. Since it is a member of a document set, its metadata is populated by ‘shared columns’ from the document set parent. This is really great, except that the columns don’t surface as Item Properties, which would allow them to be selected through the Insert Reference screen.
So Query list action to the rescue! After much head scratching and false paths, I finally figured out that all I needed to do was query the ‘list’ (document library) this document was associated with (in this case, Purchase Orders), using the URL Path (internal name is ‘FileRef’) of the selected file. Duh!
By querying the library, I now have access to all the file’s metadata for my output. I simply select the fields I need and assign each to its own workflow variable.
But wait … that’s not all! What if your query is a little more complex than the query builder can handle? You’ll note in the above screen grab that there’s an Editor Mode option called CAML Editor. How cool is that? Once you’ve selected your basic query options, you can then change modes and go into the CAML editor and tweak the automatically built CAML query to your hearts content. For me, I needed to be sure the Vendor lookup field returned the Lookup Id instead of the Lookup Value, so I was able to add the ‘LookupId=”TRUE”‘ attribute to the Vendor field. I could then use the returned id in another Query list action to pull Vendor information from the Vendors list. Nice!
TIP: If you’re querying a document library, it’s very important you check the ‘Recursive’ box found just below the list dropdown on the Configuration screen. This will add the Scope attribute needed in order to query for the item within the folders and subfolders. If this is unchecked, the query will stop at the top level and will return nothing back. I wasted more time than I like to admit trying to figure out why my query was returning no results here, while it all worked beautifully in my CAML Query helper tool.
TIP: Or caution – If you customize your CAML query, you won’t be able to go back to the ‘Query builder’ editor mode without potentially losing some of your custom changes. For example, I can change a FieldRef value and it will likely stick, but adding the LookupId attribute to a FieldRef does not. But don’t worry! A big warning is thrown when you try to change back so you won’t inadvertently lose any important changes. When/if you click OK to proceed, any losses will be intentional. J
Regular Expression Action
I know that none (or mostly none) of us really like working with regular expressions, but we can’t deny that they are a very valuable and powerful tool. One of the very cool actions that you can add to a Nintex workflow is called ‘Regular Expression.’ Why would anyone do this you might ask? In my case, I needed to figure out what the parent folder was for a document in a document set.
By using this action, I was able to write (i.e. I googled it) a regex pattern that would pull the last folder from the selected file’s URL. The output returned from this action is in the form of a collection (an array of values) that can then be looped through to extract the data you need. I chose the Split operation for my needs, but there are several other operations available as well that I haven’t had time to play with yet.
After I had my data collection, I added a simple ‘For each’ action that looped through this collection looking for the data I needed – the folder name. This particular pattern returned the match in the second item, so I just looped to the first non-empty item, grabbed the folder name and exited the loop. Pretty nifty stuff!
And that’s all I have for now. Thanks for taking the time to read all the way to the bottom!! Leave a comment below if you have any tips that you learned when first using Nintex or have a question about something I shared.