Skip navigation
All Places > Getting Started > Blog > Authors jesse.mchargue

Getting Started

15 Posts authored by: jesse.mchargue Champion

Hello again - 


I posted this question a while back and abandoned it as I was pulled in a different direction

Alas, I have returned and wanted to post my finding about it in the hope that I can save some people hours of banging their heads against their desk!


The Scenario

Simply put, I want to create a User Story in a project within Visual Studio Online. I want a user to fill out a form and then pass that information over into VSO. This is to be used for a web support team as a request form and queue for updates/changes to internal websites.


The Setup

Before we dive in, as always, lets take a minute to understand what we want to do and what we need to do.

  • Build a form to collect data
  • Build a workflow to pass data 


Simple, right? 


I do recommend that you take a look at the following sites as reference if you are unfamiliar with Visual Sudio APIs:

Getting Started: Auth Overview

Creating Personal Access Tokens

Creating Work Items


I am going to assume you have a basic understanding of Nintex Workflow 2010, and more specifically the Web Request Action, but if not, check out Nintex Help - Web Request.


The Visual Studio Parts

In order for this to all work, we need to make sure that the web service call has the proper authorization to create the work items in our project. To do this, we will create a Personal Access Token. Simple navigate to your Visual Studio Online environment and from the homepage open your profile and click on "Security".

Next you will want to Add a Personal Access Token. This will generate a unique key that you can set to expire as well as what scope it pertains to:


Once you have the key (be sure to copy and paste it somewhere because you cannot view it again after it is gone) you will need to encrypt your token in Base64 so that you can use it in an HTTP Header (which is what we will do).


When encoding your token, do not forget your login! So for example, it will look like this:



When you encrypt it, it turns out like this:



Once you have that setup we can move into the Nintex side of things


The Nintex Parts

I am not going to go over the form because I want to focus on the "how we connect Nintex Workflow to VSO".

You can make the form anyway you want with any data points and controls you see fit. Here is my form (no extras added):


I know its is not pretty, but we are going for functional! The workflow is where the magic happens so lets dive into that.

At the core, we want to leverage a Web Request action. I use some other actions to help set variables (query user profiles, etc), but the focus is on the Web Request.

You will want to use a PATCH and point your web request action to your project within Visual Studio:


PATCH https://{instance}/DefaultCollection/{project}/_apis/wit/workitems/${workItemTypeName}?api-version={version}


Your headers will be as follows:

Content-Type: application/json-patch+json
Authorization: Basic {YOUR Base64 ENCRYPTED USERNAME:TOKEN}


Lastly, you will want to add your request body. For this example, I am creating a User Story and this is the body:

          "op": "add",
          "path": "/fields/System.Title",
          "value": "{ItemProperty:Title}"
          "op": "add",
          "path": "/fields/System.Description",
          "value": "{WorkflowVariable:var_FN} {WorkflowVariable:var_LN} 
<div>{WorkflowVariable:var_Email} </div>
<div>{WorkflowVariable:var_PhoneNum} </div>
<div>Description: </div>
          "op": "add",
          "path": "/fields/System.AssignedTo",
          "value": "{WorkflowVariable:var_assignedTo}"


Web Request Action Sample:



Run Now:


I recommend that the first time you simply try to create an item with a title so you do not get hung up on all the other properties. I have had some success with doing a "Run Now". I would recommend using it, but I use Fiddler or Postman to remove any issues that SharePoint may present. More on that later.



Now that we have everything in place, let's create one and see it go through!

Form (I had someone else fill it out to test permissions at the same time ):


And here it is in Visual Studio:


It works (yay)!


Final Thoughts

I recommend doing this in Postman or Fiddler first so that you can understand how the web service work and hammer out the syntax. I spent countless hours attempting to connect to realize I left off the "username@domain" from my access token... yea... it happens.


Also, using Postman or Fiddler allows you to operate outside of SharePoint. We ran into issues trying to get the call to go out of our network... more wasted time, but figured it out in the end. Knowing that it works in one place can help determine issues and causes.


Next I want to recreate this in Office 365. I would like to use Nintex Workflow Cloud, but did not see a Web Request action yet.


Hope this helps, and as always, until next time!

Hello there!


I wanted to share some (hopefully) inspiring and thought provoking ideas. I was recently playing board games (Guess Who) with my kids and got to thinking, "How cool would it be to play a game, but using Nintex!?!? I could make a form that allows the user to pick questions from a drop down and then submit to a workflow and use a list to hold the features of all the characters...I should use the people on my team as the characters!!!!" ...and I got wayyy to excited over this  and dove into the form designer.


So what do we do when this happens? Take a breath, and a step back. Start with the basics and build up. You can't start building the penthouse if the foundation isn't poured. 


I landed on Tic-Tac-Toe, and not Guess Who, because it is a much more simplistic game and does not require too much to get it up and running. Also, there are some points functionality that can be used elsewhere. I kept the game to a single form to highlight just how simple and easy it can be to do something completely different that it's intended use. I am sure that Euan Gamble and crew did not think of a gaming platform while considering what features will or would not be added


Yet that is how the business world works! We take a core concept and then mold it into what we need it to do. There is no "one-size-fits-all", but if we understand the capabilities of the tools that we have at our disposal, we can certainly build anything. But what else can we create and build with Nintex? I have a slew of ideas for games, but I want to know what others have thought of doing.


The Game

I used JavaScripting to do the heavy lifting and some CSS to help out.


Big shout-out to Sean Fiene for the assist with the JS as it reminded me to slow down and take a step back!


Attached you will find the .nfp file for the form, simply create a new list, import this form, publish it and you are good to go!


***Please keep in mind that this is for Office365 and the JavaScripting could use some cleaning up (I am sure someone can do it better ). I am working on getting it into 2010, will post it here once I get a chance to move it over.

With the encroaching end of a major effort I have been a part of for the better part of this year, the time has come to look back and review all the things that were encountered and see if they could have been done better. I wanted to take a moment and share something that was asked of me mid-way through this project and changed how I approached the workflow.


A Bit of Background

At the core, this is nothing more than an approval process. That said, it goes through 9 different approvals ranging from service reps, to field reps, to engineers looking at installed equipment. In total, there are 5 different groups that have to touch this and within each of those groups, it may be assigned to a different user depending on geo-location.


So you may already see where I am taking this, but the issue that arose is how can we assign a task to someone but allow for someone else to jump in and take over?


Delegation right? Well delegation requires the assigned user to do the delegation. What happens if that user is unavailable? What if the supervisor needs to step in or have a "secondary" user process the step that it is on?


After some thinking I landed on assigning the task to the entire group, but only sending the notification to the specific user. This allows for the entire team to have access to complete the task if needed, but still only notifies the proper "assigned" user to complete the task.


How I Did It

This approach is simple enough.

Create the task, but do not send a notification, then, in a parallel action, send the notification.

Within the task itself, you will need to capture the task ID within a workflow variable (integer):


You will also need to set the delivery type to "None" so that the task does not generate a notification:

On the parallel branch, you will need to put a slight pause in the workflow so that the system can create the task.

Immediately after the pause step, you can add your notification. Within your notification, you will need to build a task URL using the task ID variable. So something like this:


{Common:WebURL}/Lists/Workflow Tasks/EditForm.aspx?ID={WorkflowVariable:taskID}


If you do not add a pause, the task ID variable may be blank/empty because the task ID has not been set and you are using it to create the task URL.



And that is it! You now have a task assigned to a group of users, but are only notifying a specific user(s) that it exists. This allows you and the assigned team the flexibility to shift work when needed without changing anything within the task or workflow and without bombarding users with task notifications.


Final Thoughts

As always, there is probably a million ways to approach this and I am eager to hear what others have to say and how they would tackle this. Let me know in the comments below and as always, hope this helps!

I come to the Nintex Community on a regular basis because I want to stay on top of new features.  For me, this translates into experience in what I am doing in my current job because I am learning through other's examples and feedback. I also try to leave my insight for the next user with the hopes that they will learn something through my experiences. 


This happened just the other day with the May Mission - Quick Top Tip!  I was looking over all of the great tips and tricks that other users have and while most of these are "common sense", many of them I never really took the time to practice. One in particular is to slow down and think of a plan before diving into development. Again, this makes complete sense, but how many times do we get super excited with a new project and think of all the cool things Nintex can provide for us, and then just jump right into the canvas and start dragging in actions! We have all done it, but slow down. Take a moment. Think about the process and where it is and where it needs to go.


I added to this by saying replace what you have. In terms of a process, form, or whatever you are looking to do, first step is simply replace currently functionality. This "conversion to Nintex" will naturally show you and your users areas of improvement without changing anything! From there, you can begin to add in enhancements and make "upgrades". I recommend this because too often we overlook all the work that was done previously to get the process or form to the state that it is in today. You would be surprised how much you can learn; perhaps it provides some insight on how previous developers tackled an issue or created custom functions/services to do something. All of these points of functionality can be used to your advantage, but if you rush in and just start developing, you will overlook them and possibly run into the same problems!


I share these experiences and thoughts because I think that we are all in this together; we are a community. We are here to connect and to learn. If I can save someone out there hours of frustration by writing a blog about what I did and how I overcame something, it is a win. I want to inspire others to do the same because you never know who it will help. You never know, someone may come back and give you feedback on a better way to do something! The learning never ends if we keep connecting and pushing each other.


What is Nintex?

Posted by jesse.mchargue Champion Mar 17, 2017

I have been doing a lot of "selling" Nintex to different business areas within my company lately as we gear up for the ever-looming exodus to "The Cloud", and have faced the same question more times than I really thought I would have.


"What is Nintex?"


The question is simple enough, and I could go on for hours about it, but how do you sum it up in a sentence, or a word? When you think of Nintex, what jumps to mind? What is your "elevator speech" for Nintex?


I have heard everything from "they do workflow and forms, right?" to "they do some stuff in the SharePoint space", but that hardly does Nintex any justice.


For me, I always gravitate towards "improvement". 


From existing workflows and processes to forms, it is a tool for improvement. It allows us to improve how we do our day-to-day as well as changes the way we look at approaching existing and new ventures. I think about how I can incorporate a process into other areas of the business using Nintex and how it will improve the overall experience for my users. I have been using the examples of the mobile platform and all of the things that are open to us with Nintex. This has gain a lot of momentum for me and my company, as they are starting to see that it is an improvement to the way they do their work.


I am interested to see and hear about what others think and how you approach this simple question. How would you explain it to someone that has never heard of it?


Share your thoughts and experiences, and perhaps we can each look at Nintex in a different way that we never thought of!


Until next time!

This topic came up in a question asked by Sean Docherty (Ability to cancel a workflow) and I wanted to share some of the solutions that were discussed within in a bit more detail. More specifically, I want to highlight that there are multiple ways of doing the same thing, as pointed out by our own Cassy Freeman.


The Ask

Provide users the ability to cancel a request and in-turn, terminate the workflow and any outstanding tasks.



Approach #1: Create a list level workflow that can be triggered and terminate the workflows and then delete the item.

Approach #2: Create a site level workflow that can be called to terminate the workflows and delete the item in any list.

Already we can see the differences, but each will provide us with the same end result. So let’s step through them both.


Approach #1: List Workflow

For this approach we can simply create a new workflow on the list (we will call it Delete Me). Within the workflow there are two actions; Terminate workflow and Delete item.


In the Terminate workflow action we want to stop "All except current workflow". This will terminate any other workflow(s) that are currently in flight for that specific item and in turn, any tasks that are associated to it will be removed as well.


Next we want to delete the item. This can be done using a Delete item action, and you guessed it, we want to delete the "Current item".


Simple, right? So how do we let the user kick it off? We Enable workflow to start from the item menu. This option can be found in the Workflow settings and is a check box. You can even provide a specific name, icon, and reorder it in the menu is desired.


Now that the workflow is setup, users can click on the item and select the workflow:


Once selected, it will take the user to the Start workflow page. I recommend editing the Start Form (under Workflow settings) to provide some context to the user. This can also be used as a last warning to them that they are about to delete the item! 



Approach #2: Site Workflow

For this approach we will be creating a site level workflow (we will call it Terminate and Delete). Within this workflow there three actions; Call web service, Build string, Call web service. We want to terminate any workflow, build the XML to delete the item, and then delete the item.

First we want to call the TerminateWorkflowByNameForListItem (if you are looking for it check out {yourURL/_vti_bin/NintexWorkflow/Workflow.asmx). Now we will need to feed it the information about the list, item, and workflow in question. You can also terminate any previous instances, but is not required. So how do we feed in the variables? We can use workflow variables but make them Show on start form and Required for those that are required.


Once these are setup, simply plug them into the web service fields!

With every web service call, I highly recommend testing it with the Run now action with predictable outcomes. This will ensure that your web service is setup properly and the workflow will run properly once triggered.


Next we will want to use the Build string action to create our XML to target the specific item and delete it. There are plenty of reference materials out there on the UpdateListItems method, so I will not go into too much detail here. For now, this is the XML that we want to create:

Once created, save it in our XML variable.

Lastly, we want to call one more web service to perform the deletion of the item. Since we have all the pieces in place (list name and XML) all that is left is to plug them in!

Again, do your testing so that you know it will work!


Once you are satisfied that it is setup and works properly, all that is left is to call it!


But how, you ask!?!?


At this point, you can call it however you want. From any workflow within the site, or even run it manually; the choice is yours! For this example, I have it in a state machine and can be called if the status is changed to "Cancelled". 


When an item is created,  it goes down both branches; one is for the "main" workflow while the other is to monitor for a "Cancelled" status change. This allows the user to simply change the status to "Cancelled" at any time, even if the workflow is awaiting a response from a task!


Final Thoughts

As always, there is never one way of doing something. There are different approaches and each have their own benefits and drawbacks. For Approach #1, it requires the developer to create the workflow on each list that could possibly need this functionality. On top of that, if there is a larger need to use this across multiple lists, you will soon have many of the same workflows out there... and isn't the main reason we use workflows is to reduce repetitive work? It is, however, extremely simplistic and does not take long to setup. Approach #2 on the other hand, requires some understanding of web services and how to call and construct them; something that a typical user probably does not have. It also requires some forethought on how you are planning on calling it. However, it reduces clutter by allowing any user, from any list within the site to call it; creating re-usability.


I would love to hear your thoughts on how you would approach this and if you had similar experiences and how you decided to approach the issue.


Until Next Time!

This seems to be a common ask, and this is by no means the only way to do this! This is a simple approach using out-of-the-box functionality and can be setup in a few minutes in a site workflow or a list workflow.


The "ask":

Return all users from a SharePoint User Group in First Name Last Name format.


Setup and Overview:

First step is to get the User Group name that we need to interrogate. Once we have that, we can make a web service call and get a collection of all logins, loop through them and build a list of all users. Done.


Here are the variables that I will be using:

**Note that I am doing this as a SITE WORKFLOW and have my varGroupName required and on my start form.

If you want to make this in a list workflow, you will need to alter that piece and feed it in a different way.


The workflow:

1. Get Group Name - This is simple enough, just ask for the user to type it in. Be careful though; it will try to find exactly what you put in, so if it is misspelled, you are not going to get results. We do this in the workflow start form and then feed it into the web service call.


2. Call web service - Here we want to specify the web service (GetUserCollectionFromGroup) and feed it our group name variable. Be sure to test this with an actual group name to ensure you will get results. It will also be helpful when testing and setting up the next step as well. Also, if you want to alter this, it helps to know what XML you are getting back. Then we need to store the resulting XML in a variable and we are set!

3. Query XML - Now that we have our results, we can query the XML and pull out all the users logins. If you grabbed the actual XML from the previous step, you can paste it in the XPath Builder to get the exact XPath you will need. Again, testing with actual data is better so you can see what is going on before you publish and try it. Once setup, simply store the results into our collection variable.

4. Loop for each user in the collection -

Here is where the names get pulled out and first and last names are smashed together.

In our For each action, we want to look at the collUsers and store each one (one at a time) into varUserLogin.

Using Set variable actions, set varUserFirstName and varUserLastName by looking up first name and last name from User Profile details based on varUserLogin, like so:

At this point you have varUserFirstName and varUserLastName and can do whatever you need to with it. Perhaps you need to use it in an email, or write to a list. For this example, I am going to create a full list of all users in the group. I do this by using a Build string action and adding in varUserFirstName and varUserLastName along with the varGroupUsers to continue building on top of itself.


5. Email list of users - Now that I have a full list of users, I can email myself the results:



Again, this is not "the definitive" way to accomplishing this, simply how I did it. I would be interested to know how other accomplished something similar to this, or if someone created a UDA to plug into workflows would be even better. If I have some time, I may do that.


I added the .nwf file here in case anyone wants to grab it and use it. Do note that it is a SITE WORKFLOW, but you can always create the site workflow and then save it as a snippet.


Let me know your thoughts and comments! 


Until next time!

We recently ran into a request to "archive project sites after the project has been completed" and this started to make me think of how we can automate as much as possible behind the scenes. Before we could do anything, we first had to define what "archive" meant to the end users, site owners, and us (the SharePoint team). After a few conversations, we all landed on the following:


  1. An archived site retains current permission structure, but is reduced down to read at the site level.
  2. All users will have access to the site, for historical reference, at a read level.
  3. The site will be "stamped" with an expiration date, upon which the site will be reviewed and deleted.
  4. Any content on the site may need to be migrated to team sites (for operational guides).


With these key points in mind, we can begin to really understand how to approach this. I am going to go over the first two steps here, and the others at a later time.

I do want to say that this will perform the actions at the top level of the site. Meaning, that if a user or group is applied directly to a library or a list, this process will not change the permissions that were applied through breaking inheritance.


Let's dive in!


The Setup

Before we get to the good stuff, let us go over what we need.

I did this in a UDA because we have heard similar asks from other departments, so in preparation I went ahead and did it this way. You can easily do this in a site workflow and feed it from a list.


UDA Parameters


Workflow Variables


Retaining Current Structure Reduced to Read

Honestly, at first we suggested to remove all user permissions and then grant everyone read via AD. This accomplishes the same thing, but we lose the permissions structure that was in-place. We also avoid any issues with orphaned user groups, or even removing user groups that were applied on other project sites.


First thing to do is set the permission mask variable to read. This is done by setting out variable ReadPermissionMask to 138612833.

There are a lot of articles out there regarding permission masks and what each of them are.


Next, we need to get the applied groups and update their permissions. We will use Web Service calls to get the group XML so that we can iterate through the data and perform our actions.


We can use the GetGroupCollectionFromWeb service call from usergroup.asmx to set our varGroupXML. We will go after the data from the site that is provided by the user or workflow that we require as a parameter (inputSiteURL). You will have to put in an actual site URL to generate a list of web methods, but you can then replace the URL with your variable once you are setup.



Now that we have the data, we need only to get the specific user group names. So of course we will throw a Query XML action in there and query our variable (varGroupXML). I would recommend testing the web service and seeing the XML so that you understand the structure. It helps determine the XPath needed to get the desired elements. For this, we will use the following for the XPath to get to the Name element: /defaultNS:GetGroupCollectionFromWeb/defaultNS:Groups/defaultNS:Group/@Name


It is time to do the actual updates! We will use a For each loop, and look at the varPermissionIDColl. For each varPermissionID in that collection, we want to call a web service to update the permissions. We will use the UpdatePermission web service in permissions.asmx. Just as before, we will use the inputSiteURL variable to target the specific site. We will need a bit more information on this step:


objectType: Web

permissionIdentifier: varPermissionID

permissionType: Group

permissionMask: ReadPermissionMask



That is it for the groups. If you were to run this now, all user groups on the target site would be updated to Read permissions.

While we updated all the groups, what about the users? In a perfect world, everyone would be in a group so we would not need to worry about random users being applied outside of a group...but alas we do not live there and random users are granted access outside of user groups. So to accomplish the same thing for users, you will run through the same process, but this time go after users, not groups.


Just like in the first web service call, you will want to use a method from usergroup.asmx, but this time you will want to call the GetUserCollectionFromWeb method to set our varUserXML.


Again, using a Query XML action, get a collection of names to perform the updates on. This time we will want to get login names since we are dealing with users. The XPath for this will be something like: /defaultNS:GetUserCollectionFromWeb/defaultNS:Users/defaultNS:User/@LoginName


I stored it into the varPermissionIDColl variable (you could create another variable if wanted or needed for debugging) and looped through it in the same way. This time, in the web service call, we need to make a slight change since we are dealing with users:


objectType: Web

permissionIdentifier: varPermissionID

permissionType: User

permissionMask: ReadPermissionMask


That covers all user groups and users that are applied to the site level. Last piece is to apply all users to the site with Read permissions.

We accomplish this with a simple web service call using the method AddPermission from permissions.asmx. Here is what it will look like:


Final Thoughts

This process is by no means one-size-fits-all, but it does accomplish some common asks (at least from what we have encountered). If you need to reduce all users and groups down to read, this is a straightforward way of doing things. Also, you could elevate permissions using the same process; simply change the permission mask. I have been toying with the idea of adding some logic to this to allow for permission level selection and evaluate the desired level within the workflow. This would allow for both reducing permissions as well as elevating them all within one UDA.


Also, as I said at the beginning, this only updates users and groups at the top site level. Any areas with broken inheritance will not be affected by this. I would like to explore how to "re-inherit" throughout the site, or possibly, find the areas with broken inheritance. This way no one slips through the cracks with different permissions.


Let me know what you have done or how you would approach/improve this!


Until next time.


I posted the UDA in Nintex Xchange™ titled Remove Permissions UDA  if you want to grab a copy of it.

Hello again!

I wanted to take some time and go over the Query List action as there has been a rise in questions from the community on how to leverage it. Not only the query, but what to do with the data after we query it. Let's dive right in.


Query List Action

The action is straightforward enough; query a list for specific results. An example could be all items where [Created] = {varDate} or [ID] = {varLookupID} or even just return all items (I would advise against this if possible). But how do we store the resulting data? What about if we get multiple results? If you know that the query is going to return only one item every time, then a normal variable (based on the data type it will be storing) will suffice. Otherwise, you are going to want to store your results in a Collection variable for every piece of data you want to do something with. So, if you are querying a list with 10 columns, and you only need 4 of them (to send a notification), you will need to create 4 collection variables to store the resulting data.



Collection Variables

A collection variable allows us to store a grouping of similar data types (a set of start dates, or item IDs) in an array so that we can iterate through it and utilize the data in some way. We may want to use the data to do calculations, or perhaps build a string and populate an email. So how do we do that? We can use a Loop, more specifically, a For Each loop.




We can use a For Each loop to iterate through our collection and get the corresponding data singled out. We want to start with one of our collections and store the first item in a more manageable variable. Below I used the titleColl and stored the result in itemTitle starting at the position designated by the workflow variable index. By default, you do not have to use an index, but I find it easier to manage in the event that I want to target a specific location within my collection. Also, it keeps my logic streamlined and easier to follow by someone else.

Next we need to get the corresponding data based on the where we are at in the loop. We can run these in parallel and use Collection operations to GET our variables.

Within each of our Collection operation actions, we want to get the data at the same index as the others and then store it in an appropriate variable. For example, if we want to get the item's Start Date, End Date, and ID, we would target each of those collections at the specific index and store that data in a workflow variable like so:

I am not going to go into details about the other operations that you can do with collection variables, but I highly recommend the blog posts that Paul Crawford put together on Collection Operations  and more specifically Collection Operation - Get .


Ok, so now we have the specific item details that we wanted, but what can we do with it? Short answer, anything! You now have the most granular data on that item, so here is where the "I need it to do [this]" happens. For example, if you needed to send an email notification to the [Created By] for each item, you can now do that and populate the item with specific information. We see a lot of this for reminder emails based on a specific date. Query a list based on "status" and then see if any item(s) need to trigger a reminder based on a due date.


In this example, I am building a string to put in an email. I grab the itemTitle and add it to the emailString each iteration:


Here is the list (feeling strange today ):

And here is the resulting email:


Final thoughts

One thing that I did not mention is to increment the index. This allows you to keep track of where you are in the loop and if needed, you can move back and forth using that variable. To increment index, simply add a Math operation action and increase it by 1.


I do want to mention that I have been exposed to a different way of looping through collections by Cassy Freeman. I have been experimenting with this new method and while it will provide the exact same results, it does perform a bit better with larger queries. Perhaps we can dive into that next time and shed some light on the differences and benefits!


Until next time!


P.S. - I attached the .nwf file for anyone that wants to see it in action. I am more "hands on" learner and like to see things in action and tinker to learn

I recently decided to take it upon myself to really push Nintex in our company and spread the good word of what it is capable of. I realized that this would require training on Nintex, but also on SharePoint and process in general. Below is what my initial approach has been thus far!


SharePoint, and Workflows, and Forms, Oh My!

For some, SharePoint is exciting, but for others it is dreadful! Many users have a predisposition to it and use it for specific purposes. My first step is to discuss SharePoint at a high level and give them a broad view of its capabilities. This allows me to segway into workflows, forms, and process; all of which ties in Nintex. This also lets me understand the level of exposure to these areas and what I need to focus a bit more of or glaze over if needed.


Understanding SharePoint and Processes

I like to ask questions and get participation from my audience so it keeps them engaged and thinking. I generally ask the following to get it started:

  • How much exposure to SharePoint do you have?
  • Do you understand the difference between a site and a site collection?
  • What about a page and a site?
  • A library vs a list?
  • What about workflows or processes?
  • What about your customers (other business areas)?


This gets them really thinking about just how much they truly understand and how they can improve upon it. I also like to make logical connections; tell a story, or example to drive home your points. I typically talk about my morning routine with my 3 kids and if the process breaks in the morning, well...hungry kids, late to work, you know the drill! Again, this gets them thinking about processes in a different way and that everything has a process, and, again, lets me tie Nintex into the conversation nicely.


What is Nintex?


Talk about Nintex, seems simple, but really just talk about the company. What they are doing, what they have done, what they can do. One thing I always mention is "Workflow for Everyone", it really drives the idea home to users. Highlight the areas that most interest your company and how they can solve issues you are currently facing. For me, I am pushing mobile platform because we have half of our work force in the field. Giving them the ability to connect to processes in the field (big or small) is a win! I like to hit on product features for those I am training to ease them into it and assure them that they do not need to know code, or request additional software.


Showing off Nintex

Always have examples of what you are currently using Nintex for. This shows off the product and provides you a platform to stand on when demoing something. It could be something small to demonstrate functionality, or something complex to show off how easy Nintex is to use and step through. Either way, it gives your audience something to look at and see in action, and not just you talking to them! Also, I like to walk them through a "how to use Nintex" if time allows (or if another session is required), but this lends more towards specific training on the products.



Again, seems simple, but allow time for questions. I found that if you try the "ask anytime" approach, your timing is always off. Bake in 15 minutes at the end of any questions. I also like to have some questions for the audience as well to kick it off. I generally ask what they want to use Nintex for as well as what their customers have been asking for that we could do with Nintex.



So how do you approach training/teaching users about Nintex? Any "templates" that you use? I like to see how others handle sessions so let us know how we can all improve our own training!


Until next time!

Hello All!


So I have come across some questions and discussions around the out-of-the-box web parts that Nintex provides for reporting and I wanted to dive.

Before we go on this adventure, but sure to check out Enable Reports on your Nintex Workflows by Emily Billing, it will help provide some background!

Also, these web parts are a part of the Enterprise Edition.


Turning On Your Reports

Seems silly, but make sure it is plugged in...

At a minimum you will need to turn on Nintex Workflow and Nintex Workflow Reporting Web Parts at the Site Collection level.

You may want to turn on Nintex Workflow Enterprise Reporting at the Site level so that you can leverage those reports, but for this I will be covering reports that you can show off to users and paint a picture of what they are doing.


Adding Reports To A Page

Once we have everything turned on, we can begin to start using them! I created a page and just started throwing web parts on it!

I recommend that you use something to structure the layout so it is not overwhelming (I just used a table...)!

On your blank page, open it up in edit and Insert a Web Part:


I tend to use more charts than the report viewer only because it is easier for users to consume images rather than the raw data, but I do mix it in for the ones that are more analytical and like to see it (use what makes sense to you and your needs). Once added to your page it is time to configure it, and this is where you will sink most of your time!


Setting Up Your Reports

First you have to decide what you want to report on. Again, check out Emily Billing's post I linked above of an overview of the reports.

I selected 30 Day Usage Summary (all sites).







Next we need to Configure display settings and select a few options (I put what I selected in [BRACKETS]:

  • Chart Type - [Bar]
  • Width - [720]
  • Height - [540]
  • Display Style - [2D]
  • Group Labels by - [Column]
  • Colors - I added one of each of the default colors and applied to the Rows

I also adjust the column settings to show Period and Workflows Started, and have EventDate hidden.

Click Apply and should have something to display how many workflows have been started each day over the past 30 days within that Site Collection (depending on how your db's are setup). Here is mine once all setup:


I setup four charts as a sort of "dashboard" as an overview of what is going on within the one site collection. I created charts for:

  • 30 Usage Summary
  • Workflows By Site
  • Workflow Performance - showing off duration
  • Workflow Performance - showing off the number of instances of each workflow


Here it is in action:


The "Why"

All too often we get these tools and struggle to figure out why we need/should use them and what we can use them for. Here is my thinking...

  • Reports are visual - it puts something that is easily consumable in front of users (or someone) and allows them to glean the information quickly
  • Reports provide facts, not opinions - if you see a spike in duration, you can quickly pinpoint where the problem is and how to isolate it, or if a workflow is used 75% out of all usage (as like the one I have), you can make the case to spend more time/resources to improve it or understand how important it is
  • Reports are always watching... - if someone is asking about long running instances or wants to know what is pending/errored out/canceled/etc, you can pull that quickly and know that it is accurate and up-to-date


I personally use the reports to help guide our efforts and decisions towards the important areas, rather than the vocal minority. We can provide these insights to our business areas and let them see how things are performing, how long workflows are taking, what/who is a bottleneck or unneeded step. Ultimately, it provides us the tools and facts to stand on when asked questions in regards to our workflows!


Hope this provided some insight to Nintex Report web parts and please feel free to let us know what you are using it for. I am eager to see if anyone has augmented the XML behind these or created their own custom report(s).


Until next time!

Found this picture I took at InspireX and shared with my team and wanted to share it with you!


I recently started to expand our training to involve our Business Analysts so that they can assist in getting other areas on board with Nintex. I use this image (and phrase) throughout as it drives home the idea that Nintex does not require you to be a technical savant and code solutions.  It empowers users to see and hear this as it removes the notions that it is too complex or difficult to do themselves, and once they see how easy it is to demo, that is when I see all the gears starting to move about their ideas and what they want to automate!


Work Smarter Not Harder.JPG


So what else do you guys use in your trainings? I am putting together a training packet and will most likely share it once I have it completed to get some feedback!

The idea of a "dashboard" comes up a lot and for me, I generally cringe at the thought. Not because it is difficult to implement, but because it is difficult to implement well enough so that the customer uses it frequently enough to get value out of it.



I recently had to deal with such a case with an internal customer where they wanted a form to be submitted on a child site and then certain pieces be promoted up to a parent site list upon submission. So how do we accomplish this? I used Web Services within a Site Collection workflow that is triggered by a content type. Simple enough, but requires a bit of knowledge in regards to what is expected and what to look for (a lot of trial and error )



I am not going to go into too much detail about Content Types, but I recommend knowing how to use Content Types and how to apply workflows to them. Perhaps that will be another blog for another day. This is what I am working with:


Master List on Parent Site - this list is used to build views from data that is coming from multiple child sites. Here is where you want to define the columns you want to write to and how you want to build your views/dashboard. I added columns to mine so that I can match records based on project name and ID. This allows everything to be in one location, but sometimes you need to separate out data, so do what makes sense to you.


Forms Library with specific Content Type on Child Site - this library will be where the form is submitted to and certain columns are promoted out. I used InfoPath for this only because I cannot figure out how to promote out columns to a library using Nintex Forms! If you do know or have any thoughts/ideas on this, please let me know in my question Promote form controls to another list. In regards to the content type, it is empty (there are no site columns associated to it), as we are leveraging it so we can easily identify content as it is being added to multiple sites.


Site Collection Workflow - this workflow will trigger anytime something new is created with the specific Content Type. This is the "man behind the curtain"; the one that does all the heavy lifting!






The Process:

The overall flow of this process is simple enough; a user fills out a status report and submits it to a library. The workflow is triggered (because of the content type) and then interrogates it to get additional data to push up to the master list. So lets dive into the workflow actions!


The Workflow:

First let's open up the first action set. Ultimately, we need to query the library for the data we want, but before we do that we need to know how to do that.

We can use the web service action and call the GetListItems method from ..../lists.asmx. We will need to feed it a few items at a minimum:

List Name

You could use a variable here if you want to leverage this for multiple list updates

Query (XML)

What item(s) are you going after? For this example I am going after the Current Item so I can use the ID like this:

View Fields (XML)

What fields do you want back? Simple enough, but be careful of what the columns are named as the internal name may be different than the display name (wasted a lot of time figuring that out!). Here is what I am using:

Query Options (XML)

How you want it displayed. I do not use anything here, but still need to pass in something. I added a build string action in the event that something needs added later I have something in place already. So for now I am using:


Once this all gets packaged up in XML and saved into workflow variables, simple add them into the Web Service action and save the the result set!

But now all we have is a bunch of XML data, so what's next? If you are thinking coffee then go get some! If you are thinking Query XML you nailed it!

With the result set we can pick out the specific data that we want to use and push up. This can be tricky if you are not familiar with using XPath but there are plenty of examples that you can follow such as How to extract output values from SOAP response message with Query XML action? or Dictionary Part 2 - Query XML results into a Dictionary. I generally have to lookup the exact XPath Syntax and reference that site often.


Once you have a handle on that you can add an output for each point you want to grab like so:


Almost there! We queried the library for the item and grabbed the data. We parsed through the data to get it into a format that we can leverage. Now we just need to update the Master List. Call another Web Service!

Just like before, we need to know how to feed the web service so we are updating the right item. This time since we are updating it is pretty straightforward; need the list name and updates.

List Name

You could use a variable here if you want to leverage this for multiple list updates

Updates (XML)

The updates to be made on the target list. Here is what I am doing:

I am finding the specific item to update and then pushing in the variables that I captured from the XML.


There are other Cmd's that can be used such as New and Delete if you needed to add a new record or delete something rather than updating it. I would recommend good 'ol MSDN for more information.






Final Thoughts

With everything in place, we can now have users submit a form to a library on a child site, and have specific columns be promoted out of the of the form and up to the master list on the parent site.

This allows us to build views for dashboards so that (in our case) executives can see, at a glance, the status of all projects from a central location.

With this workflow, we can also add in notification steps if needed, or even updates to other locations. Most importantly, because it is being triggered on a content type, we can apply this content type other places within the site collection and be tied into this workflow with almost zero effort!


Please let me know what your thoughts are on moving content around and out of sites and how you have leveraged web services!


Until next time!

Recently the topic of a state machine came up with Sean Docherty. I wanted to put thoughts to paper so that I can share my experience with the community and see what others view points are.


The Scenario

In this example I am creating a workflow for a software acquisitions process. Below is a high level view of the steps taken:

1. The user fills out a basic form requesting software

2. The planning team updates the form with the PRODUCT ID

     a. The workflow checks to see if it has been CANCELLED

3. A task is generated for the requester's supervisor to approve

     a. If approved, the planning team schedules an INSTALL date and completes the request

     b. If denied, the requester is notified with details on why

     c. If no action is taken with 24 hours, the request is automatically cancelled


For the sake of this post I am going to keep the form piece of it out and focus on the workflow that is driving the process.


The Workflow



The workflow is setup to trigger when a NEW item is submitted. Upon entry, the item enters the state machine in the NEW branch and waits for someone from the planning team to select a PRODUCT ID from the company catalog. We also check to see if the status is 'Cancelled' just in case someone cancels the request prior to requesting approval. The workflow then moves over to the PENDING branch. Here is where the task is generated and requests supervisor action. There is three possible outcomes:

     1. Approve - The supervisor approves the request and moves the workflow into the APPROVED state.

     2. Reject - The supervisor rejects the request and moves the workflow into the DENIED state.

     3. If no action is take within 24 hours, the task is escalated and automatically completed and moved into the CANCELLED state.


If the request is approved, the workflow waits for someone from the planning team to update the request with the date for the software install. At this point, the workflow finishes and the request has been completed. If denied, the requester is notified with details regarding why, and the workflow finishes. Lastly, if the request is cancelled due to inactivity, the requester is notified and provided explanation on why and what to do if wanting to re-submit. This is accomplished buy using the Escalation part of the Flexi Task action (see below).



Additional Thoughts

I try to use a State Machine in my workflows when an item has a life-cycle that is short and needs to be monitored. I look for short life-span so that I do not have workflows running for extended periods of time. Also, for this example, because we are updating the 'status' of the item with each new state, we can build a view within SharePoint that provides an up-to-date look at what is coming in, being worked on, and at what stage it is in. I am also attempting to leverage more of the 'Expected Duration' piece of the actions I use and monitor where things bottleneck or take almost no time. To do this, simply look in the Common section of the action and select a duration.


As always, there are many different ways that this could have been accomplished; you could use a switch action and evaluate the status each time or you could make the entire thing linear. I choose to use a state machine because it allows me to see what state an item is in at any moment and it provides me greater opportunity when I go back and automate more. For example, I would create a process that looks up the available products from the catalog and picks an open license or notify the planning team that a purchase is required (a whole new process). This step could easily be injected into the current workflow under the NEW state and not disrupt or require redesign.


Please, let me know what you think or what you have experienced regarding state machines!


Until next time!

Know your process

"Know your process”, this seems like a simple, straightforward statement, but I found that many users just do not know it as well as they should. I wanted to share my thoughts, findings, and approaches on how I tackle this within my own company and hope to hear about how you, as a workflow developer or form guru, approach your customers.


Initial idea

We all have been in those meetings where someone says "this would be a good candidate for a SharePoint workflow and/or form", and dread the next steps (or you get giddy and excited over a new chance to prove your skills...I geek out way too much!). The flood of a million questions starts to pour in: Why SharePoint? Are we replacing something existing? Is the current process broken? Who owns this? And so on. For me, I take this time to gather my own information. I pour over the current process as an end user and see what the experience is TODAY, and take notes on its strengths and weaknesses. With this in hand, I can hold an intelligent conversation with the process owner as well as the stakeholder.


Requirements Gathering

There are a lot of different approaches on this so I am going to stick to what I know and what works best for me. I will meet with the process owner; the one that uses the form the most or manages the process. This way I am really getting the most out of what NEEDS to happen rather than what people WANT to happen. Here is where I see what the process does behind the scenes and begin to understand how we can translate it into SharePoint and Nintex. This is also when we see just how much of the process is unknown, undocumented, or (my favorite) "well that is just how we have always done it". At this point it can go one of two ways; start developing a solution because the process is detailed out and you have a clear understanding of what needs to happen (I am beginning to think this actually doesn't happen...) or we go back to the owner and help them detail out their process.


Detailing out the process

Let’s say that for some crazy reason your process is not detailed out (pretend if you have to). What I like to do is get the process owner involved. They can tell me what happens for each step at a high level. I have even started to ask owners to create a simple Visio diagram of the workflow so that way they can visualize it, but if I cannot get that piece, I generally white-board it out. This also lends a hand to the owner so they can see just how the process works and see if they are missing or overlooking something because it has been ingrained in them over the years. I try to ask questions along the way and challenge the process where I can; do we need to email them multiple times or can we do it once at the end? Do we need to do multiple web service calls or can we consolidate down? Sometimes we find new ways; sometimes we learn that it HAS to be a certain way due to security. Either way, it gets both sides involved and understanding the process inside and out. It helps to show all of the expected outcomes and what items are needed along the way. Once I have this, I have a blueprint for what I need to develop.


Developing a solution

For me, I spin up a site in our test environment and start building. This gives my customer a tailored site that is just for them and it keeps everything else clean; I know what I am testing and where the tests are located. Once I have a stable version of the process, I open it up to the customer and say "have at it!” I force them to meet with me, face-to-face, and review what they like, dislike, want, don't want. The reason I do face-to-face is that emails get lost, glazed over, and generally ignored. This forces the customers to engage with me and take a look at what is going on. It also allows them to have a voice and feel as if they are building it too. I ask the customer for when they want to start using it and try to manage expectations from there. We all know that this is not one and done, but a reiterative in nature. Meaning that it takes time to develop, a lot of back and forth, but we can provide working solutions and with customer feedback we can refine the process as it evolves.


Going back

All too often we deliver a process to a customer and a few weeks later they reach out and have changes. This is because they did not account for something or the user experience is not exactly how they envisioned it. This is generally not a big deal since we can update workflows without taking outages. We can update forms without major interruptions. We can add new logic to lists without anyone noticing. Even if your process is "set it and forget it", I do encourage you to go back and take a look at it again and ask yourself is there a better way? I find myself learning new things from this community every day and am blown away how much knowledge and passion there is out there for Nintex.


Please let me know your story and what tips or tricks you use to translate the needs and wants into working Nintex solutions.


Until next time!

Filter Blog

By date: By tag: